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ABSTRACT 


This  thesis  investigated  the  current  infrastructure  for  web-based  simulations 
using  the  DIS  network  protocol.  The  main  technologies  studied  were 
WebSockets,  WebRTC  and  WebGL.  This  thesis  sought  readily  available  means 
to  establish  networks  for  interchanging  DIS  message  (PDUs),  so  the  WebSocket 
gateway  server  from  Open-DIS  project  was  used  to  construct  a  Client-Server 
structure  and  PeerJS  API  was  used  to  construct  a  peer-to-peer  structure.  WebGL 
was  used  to  create  a  scene  and  render  3D  models  in  browsers.  A  first-person- 
shooter  tank  game  was  used  as  a  test  application  with  both  WebSocket  and 
WebRTC  infrastructures. 

Experiments  in  this  thesis  included  measuring  the  rate  of  sending  and 
receiving  DIS  packets  and  analysis  of  the  tank  game  by  profiling  tools.  All  the 
experiments  were  run  on  Chrome  and  Firefox  browsers  in  a  closed  network. 

The  experimental  results  showed  that  both  WebSocket  and  WebRTC 
infrastructures  were  competent  enough  to  support  web-based  DIS  simulation. 
The  results  also  found  the  significant  differences  of  performance  between 
Chrome  and  Firefox.  Currently,  the  best  performance  is  provided  by  the 
combination  of  Firefox  using  the  WebRTC  framework.  The  analysis  of  the  tank 
game  showed  that  most  of  the  browser’s  computational  resources  were  spent  on 
the  WebGL  graphics,  with  only  a  small  percentage  of  the  resources  expended  on 
exchanging  DIS  packets. 
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I.  INTRODUCTION 


In  the  military  domain,  simulation  is  widely  used  for  training,  education, 
and  analysis.  Many  simulation  systems  have  been  developed  to  support  different 
missions,  such  as  flight  simulators  for  training  and  educating  pilots,  or  Virtual 
Battlespace  2  (VBS2)  for  educating  platoon  leaders.  After  multiple  simulation 
systems  have  been  established,  users  may  want  to  integrate  them  for  joint 
training  purposes.  Therefore,  the  requirement  for  interoperability  among  systems 
becomes  an  important  topic. 

In  the  1990s,  the  Simulation  Interoperability  Standard  Organization  (SISO) 
reached  an  agreement  on  a  distributed  interactive  simulation  (DIS)  protocol. 
SISO  also  had  the  DIS  protocol  ratified  as  an  IEEE  standard,  so  it  is  now 
available  for  anyone  to  read  and  implement.  Currently,  the  DIS  protocol  has  been 
used  to  develop  many  simulation  systems  or  communicate  among  existing 
systems  by  formatting  the  exchanged  data.  There  are  many  existing  simulation 
systems  that  have  implemented  the  DIS  protocol  by  different  programming 
language  (Rogerson,  1997;  McGregor,  Brutzman  &  Grant,  2008).  One  purpose  of 
military  simulation  is  to  construct  a  live,  virtual  and  constructive  (LVC) 
environment  for  military  training,  education,  and  analysis  (Farlane  et  al.,  2004). 
“Live”  refer  to  real  people  operating  real  systems  such  as  real  pilots  flying  F-16 
fighters.  “Virtual”  refers  to  real  people  operating  simulated  systems,  such  as  real 
drivers  in  high-occupancy  vehicle  (HOV)  simulators.  “Constructive”  describes  a 
simulation  in  which  both  people  and  systems  are  simulated  such,  as  a  simulated 
opponent  force— an  opponent  fighter  with  Al— in  a  simulated  system.  In  order  to 
achieve  LVC  architecture,  simulation  systems  have  to  exchange  information  with 
each  other,  and  DIS  protocol  represents  a  standardized  format  for 
communicating  data. 

With  the  developments  of  web  technology  and  the  improvements  of 

computer  performance,  more  and  more  applications  can  be  run  in  web  browsers. 

This  thesis  implemented  several  web  technologies  that  mainly  included 
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WebSocket,  WebRTC,  and  WebGL  to  discuss  the  feasibility  of  applying  DIS 
protocol  to  multiple-user  web-based  simulation.  The  client/server  and  peer-to- 
peer  architectures  can  be  used  to  develop  web-based  simulations,  and  their 
respective  technologies  are  WebSocket  and  WebRTC.  This  thesis  compared  the 
performance  of  sending  and  receiving  DIS  messages  in  these  two  different 
networking  architectures,  and  incorporated  WebGL  components  to  develop  a 
first-person-shooter  game  to  analyze  the  performance  in  different  browsers. 

This  thesis  also  discussed  the  advantages  of  web-based  simulation.  The 
features  of  web-based  simulation  are  easier  to  upgrade  (centralized  content),  are 
cross-platform,  and  are  widely  accessible  via  computers,  tablets,  and  mobile 
devices.  For  example,  when  people  want  to  execute  simulation  systems,  they 
have  to  set  up  an  environment  for  execution.  This  environment  includes  a 
physical  desktop  setup,  an  operating  system  install,  a  simulation  software  install, 
and  a  peripheral  device  setup.  Typically,  computers  have  pre-installed  operating 
systems  with  peripheral  device  setups.  The  simulation  system,  however,  has  to 
be  installed  additionally,  and  each  one  has  its  own  compatible  operating  system 
(e.g.,  Windows  7,  Windows  Server  2012,  UNIX,  and  different  versions  of  Linux). 
When  users  want  to  run  a  specific  simulation  system  on  computers,  they  have  to 
check  and  configure  all  operating  systems  and  system  setups  before  running  the 
simulation.  The  computer  preparation  for  running  this  specific  simulation  system 
may  be  a  tedious  and  inefficient  process. 

Web-based  simulation  can  relieve  the  above  situation  and  increase  the 
efficiency  of  system  readiness.  Nowadays,  the  major  browsers  that  most  people 
use  on  desktop  and  laptop  computer  are  Chrome,  Firefox,  Internet  Explorer,  and 
Safari.  All  the  experiments,  comparisons  and  analysis  in  this  thesis,  however, 
were  run  in  Chrome  and  Firefox  because  both  Chrome  and  Firefox  support  the 
same  web  technologies.  In  addition,  both  Chrome  and  Firefox  provide  installers 
for  mainstream  operating  systems  such  as  Windows,  Mac  OS,  and  Linux,  so 
web-based  simulation  can  run  on  almost  every  operating  system  through  these 
two  platforms  (Chrome  and  Firefox). 
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The  thesis  begins  by  describing  the  motivation  and  the  benefits  of 
browser-based  simulation  and  outlining  the  technologies  for  constructing  the 
infrastructures.  Next,  the  thesis  describes  design  and  implementation  for  testing 
the  performance  among  several  variables.  The  latencies  and  the  results  were 
discussed  at  the  end  with  commentary  for  future  work. 
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II.  BACKGROUND 


In  the  past,  developing  a  networked  and  interactive  simulation  system 
usually  required  complex  programming  skill.  Many  programming  language  and 
technologies  have  been  developed  to  reduce  the  complexity  of  programming. 
The  following  sections  describe  motivations  and  several  present  technologies  for 
developing  a  small-scale  and  interactive  simulation. 

A.  MOTIVATION 

With  the  prosperity  of  the  Internet,  more  and  more  web  applications  have 
been  developed.  With  the  development  of  web  technologies  and  the  increasing 
of  computational  power,  the  possibility  of  developing  interactive  and  complicated 
applications  in  web  is  promising,  and  because  of  the  elements  of  interaction  and 
logical  computation  capability,  web-based  simulation  systems  are  more 
achievable.  Web-based  simulation  is  exploiting  resources  and  technologies 
offered  by  the  World  Wide  Web  (WWW)  to  represent  traditional  simulation 
systems  (Fishwick,  1996).  In  other  words,  web-based  simulation  uses  web 
browsers  as  graphical  interfaces  to  link  users  and  simulation  systems.  The 
benefits  of  exploiting  web-based  simulation  are  cross-platform,  collaboration, 
model  reusing,  deployment,  wide  availability,  versioning  control,  etc.  Modern 
browser  companies  provide  browser  installers  for  different  operating  systems, 
and  most  modern  browsers  support  the  same  web  technologies  (e.g.,  JavaScript, 
JSON,  binary  data  format,  WebGL,  and  WebSocket),  which  increases  the  cross¬ 
platform  capability.  Collaboration  is  useful  in  that  web  simulations  can  be 
designed  to  help  people  involved  in  a  common  task  to  accomplish  goals.  Model 
reusing  is  that  many  existing  3D  graphic  formats  such  as  .dae,  .obj,  .blend  can 
be  imported  into  web  applications,  so  software  engineers  can  focus  on  the 
design  of  web  applications  rather  than  making  3D  models.  Web  applications  also 
increase  their  accessibility  and  deployment  to  users  because  every  operating 
system  has  its  compatible  browsers  that  support  the  same  web  technologies.  On 
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server  side,  web  applications  can  ease  the  burden  of  versioning  control  for 
system  managers.  They  only  need  to  update  archives  on  server  and  ask  users  to 
reload  and  refresh  web  contents.  Additionally,  web  applications  are  easy  to 
execute  because  browsers  do  not  need  further  configuration  or  plug-in  to  run 
applications.  For  the  military  domain,  state-of-the-art  web  technologies  can  not 
only  construct  web-based  simulations  (McGregor  &  Brutzman,  n.d.),  but  also 
enable  communication  between  web  applications  such  as  Google  Maps  and 
existing  simulation  systems  such  as  VBS2,  OneSAF,  and  JCATS  via  proper 
gateways(McGregor,  Blais,  &  Brutzman,  n.d.).  The  ability  of  interoperating  with 
other  systems  increases  the  practicability  of  web-based  simulation.  Furthermore, 
inventors  of  web  technologies  also  ease  the  learning  curve  of  developing  web 
applications.  HTML5  and  JavaScript  are  easy  to  learn  and  practice  programming 
languages,  and  developers  do  not  require  compilation  JavaScript  manually  or 
extra  procedures  for  users  to  run  web  applications. 

B.  TECHNOLOGIES 

In  order  to  establish  a  web-based  simulation  with  the  abilities  of  easy 
deployment  and  maintenance,  many  elements  have  to  be  applied.  These  include 
networking  architecture,  DIS  protocol,  JavaScript,  web  server  with  WebSocket, 
Web  Real-Time  Communication  (WebRTC),  WebGL,  JSON  format  DIS,  and 
binary  format  DIS  messages. 

1.  Networking 

Networking  is  separated  into  five  layers:  application,  transport,  network, 
link,  and  physical.  Most  of  the  applications  are  implemented  in  the  application 
layer  over  TCP/IP  protocol,  a  framework  for  communication  between  devices. 
TCP/IP  is  a  software  concept  that  allows  one  machine  to  send  bytes  to  another, 
without  knowing  the  content  or  meaning  of  those  sent  bytes.  Applications  are 
used  to  interpret  TCP/IP  sending  data.  Modeling  and  simulation  (M&S) 
networking  protocols  are  standardized  in  the  application  layer,  and  all  the  M&S 
applications  such  as  JCATS  and  OneSAF  relay  on  this  layer,  too. 
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Network  architecture  usually  contains  more  than  two  hosts  (Steed  & 
Oliceira,  2010,  Ch.  4)  in  military  simulations,  so  it  is  important  to  define  models 
for  multi-host  connections:  simple  peer-to-peer,  peer-to-peer  with  master  host, 
peer-to-peer  with  rendezvous  server,  and  client/server.  Simple  peer-to-peer 
communication  means  that  each  host  has  a  configuration  file  to  record  necessary 
information  of  all  the  participants  (as  well  as  address/port  data)  and  then  sends 
updates  to  all  the  other  hosts  within  the  network  group.  Peer-to-peer  with  master 
means  that  one  the  participants  will  be  the  rendezvous  access  point.  The 
rendezvous  point  has  a  well-known  IP  and  port  number,  so  any  host  who  wants 
to  join  the  network  can  obtain  other  participant  information  from  the  master.  The 
advantage  over  the  simple  peer-to-peer  model  is  that  there  is  no  need  to  collect 
every  participant’s  IP  address,  port  number  and  other  information  beforehand. 
The  peer-to-peer  with  rendezvous  server  model  uses  a  server  that  has 
information  for  all  participants.  Every  host  who  wants  to  join  the  network  has  to 
connect  to  the  rendezvous  server  first  to  ask  for  network  environment 
information.  The  difference  between  peer-to-peer  with  master  and  peer-to-peer 
with  rendezvous  server  is  that  the  master  is  one  of  the  network  participants  but 
the  rendezvous  server,  who  is  not  a  participant  in  the  network,  is  only  the 
distributor  with  all  the  hosts’  information  for  a  new  host  who  wants  to  join  the 
network.  Client-server  architecture  means  that  each  host  connects  to  the  server, 
and  the  server  is  responsible  for  every  communication  between  hosts. 

2.  DIS  Protocol 

DIS  is  a  standardized  protocol  used  to  communicate  and  exchange 
information  in  a  multiplayer  simulation  system  (DIS  IEEE  Std  1278.1 -2012- 
Standard  for  Distributed  Interactive  Simulation-Application  Protocols,  2012).  It 
also  allows  two  or  more  different  types  of  simulators  to  interact  or  interoperate, 
especially  those  simulators  that  have  human-in-the-loop  elements.  For  example, 
a  joint  forces  exercise  uses  ship  simulators  and  flight  simulators  to  train  the 
capability  of  cooperation.  The  method  that  DIS  uses  to  interchange  information  is 

based  on  protocol  data  unit  (PDU)  messages;  there  are  many  kinds  of  PDUs, 
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such  as  entity  state  PDU  (ESPDU),  detonation  PDU  and  entity  damage  status 
PDU.  Different  PDUs  have  different  lengths  and  fields  to  contain  the  variety  of 
information,  so  simulation  system  can  communicate  with  each  other  by  sending 
and  receiving  PDUs.  Although  there  are  many  kinds  of  PDUs  with  different  fields 
for  restoring  information,  every  PDU  starts  with  the  same  header  that  is  used  to 
differentiate  PDU  types  when  receiving  DIS  packets.  Appendix  A  displays  a  table 
containing  entity  state  PDU  fields,  and  shows  that  the  common  PDU  header  used 
the  first  96  bits.  The  table  also  shows  the  other  fields  of  ESPDU.  ESPDU  is  the 
most  frequent  PDU  in  DIS  simulation,  and  it  is  used  for  interchanging  the 
information  of  entity’s  state.  The  information  includes  entity  ID,  entity  type, 
location  and  orientation  in  the  simulated  world,  entity  appearance,  entity 
capabilities,  etc. 

The  DIS  uses  a  heartbeat  strategy,  in  which  entities  periodically  send  out 
their  PDUs  even  if  they  do  not  change  their  properties  or  states.  A  critical  issue, 
however,  is  the  rate  at  which  each  entity  sends  its  PDUs— sending  data  too  often 
would  cause  networking  congestion,  latency  or  losing  data,  etc.  In  a  large-scale 
scenario,  some  of  the  entities  are  relatively  slow  or  even  in  a  static  state  (e.g., 
tanks  or  infantry),  but  some  of  the  entities  move  quickly  (e.g.,  airplanes). 
Therefore,  the  developer  has  to  set  different  update  rates  for  different  kinds  of 
entities  to  avoid  redundant  DIS  packets  transferring  in  network.  Another  principle 
is  not  to  let  the  late-joining  hosts  wait  too  long  for  those  slow-moving  entities.  DIS 
simulation  is  mainly  used  in  military  domains,  and  it  usually  assumes  that  DIS 
simulation  is  implemented  in  a  high-performance  intranet  with  high  security,  one 
in  which  participants  will  not  send  fake  or  swindling  messages.  Additionally,  in 
order  to  simplify  data  transfer,  DIS  usually  broadcasts  or  multicasts  its  PDUs 
based  on  UDP  socket. 

3.  JavaScript 

JavaScript  is  the  scripting  language  of  the  web,  and  all  modern  web 
browsers  support  JavaScript  (w3schools,  n.d.).  JavaScript  lets  browsers  have  the 
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capability  of  logical  computation  and  client-side  scripting  that  let  users  change  or 
interact  with  web  content  depending  on  user  input,  which  is  in  contrast  with 
server-side  scripts  such  as  PHP,  Java  and  Python  (Flanagan,  2011;  Powers, 
2010). 


4.  Web  Server  with  WebSockets 

Traditional  web  servers  only  talks  to  a  user’s  page  once,  when  user  loads 
the  content  from  the  web  server;  this  is  because  the  web  pages  were  designed  to 
be  static  originally.  This  causes  a  problem  for  web  pages  that  need  highly 
interaction  with  users.  With  WebSocket,  JavaScript  opens  a  TCP  socket  to 
establish  a  communication  channel  to  the  server  and  request  this  special  type  of 
TCP  socket  to  be  opened  for  delivering  arbitrary  application  protocols  between 
client  and  server  (Grigorik,  2013,  Ch.  17).  This  specialized  TCP  socket  can 
remain  open,  so  web  pages  can  keep  updating  its  contents  periodically  with 
some  JavaScript  program.  Furthermore,  WebSocket  also  has  features  of  low 
latency  compared  to  FITTP  polling;  and  higher  bandwidth.  WebSocket  makes 
possible  to  run  interactive  and  real-time  applications  in  web  browsers. 

5.  WebRTC 

WebRTC — whose  API  is  defined  by  W3C  and  protocol  is  defined  by 
IETF — is  a  plugin-free  real-time  communication  API  that  is  used  for  high-quality 
audio,  video  and  data  communication  with  low  cost  (“WebRTC,”  n.d.).  The 
features  of  WebRTC  are  binding  a  UDP  socket,  peer-to-peer  connection,  and 
cross-platforms  interaction.  Four  main  tasks  for  WebRTC  are  acquiring  audio  and 
video,  establishing  a  connection  between  peers,  communication  audio  and  video, 
and  communicating  arbitrary  data.  In  order  to  achieve  the  above  tasks,  three 
main  JavaScript  APIs-MediaStreams  (a.k.a.  getUserMedia), 
RTCPeerConnection  and  RTCDataChannel  are  applied.  So  far,  WebRTC  can 
run  in  Chrome,  Firefox,  and  Opera. 

MediaStreams,  acquiring  audio  and  video,  represents  a  stream  of 

synchronized  media,  and  it  can  contain  multiple  audio  and  video  tracks.  To 
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obtain  a  MediaStream,  JavaScript  provides  a  method  called 
navigator.getUserMedia().  When  invoking  navigator.getUserMedia(),  a  web 
browser  will  pop  out  a  HTTPS  prompt  and  ask  the  user’s  permission  for 
accessing  the  camera  and  microphone.  While  developing  web  apps  using 
WebRTC  API,  developers  can  combine  video  and  audio  streams  with  JavaScript 
Canvas  and  WebGL.  In  the  mobile  devices  with  multiple  cameras  or 

microphones,  users  can  choose  input  devices  through  WebRTC  API.  Another 

function  of  WebRTC  is  getUserMedia()  for  capturing  user’s  screen,  which  is 
useful  for  desktop  sharing  or  online  remote  teaching. 

RTCPeerConnection  is  implicitly  used  for  audio  and  video  communication 
between  peers.  A  web  browser  takes  the  media  streams  from  getUserMedia(), 
plugs  them  into  the  peer  connection  and  sends  them  off  to  the  other  side.  The 
peer  connection  is  responsible  for  many  things  (e.g.,  signal  processing,  codec 
handling,  peer  to  peer  connection,  security,  and  bandwidth  management). 
WebRTC  hides  most  of  the  complexity  from  web  developers,  so  developers  can 
get  media  streams  easily  and  plug  them  into  peer  connection. 

RTCPeerConnection,  however,  needs  servers  to  broker  a  connection  when  the 
peers  want  to  make  connections.  Therefore,  a  process  called  signaling  is 
applied,  which  is  like  making  a  telephone  call.  When  a  caller  makes  a  phone  call, 
the  telephone  network  sends  a  message  to  a  callee.  After  the  callee  answers  the 
call,  the  callee  sends  a  message  back  to  activate  a  connection.  WebRTC  does  a 
similar  thing.  When  a  peer  wants  to  establish  a  connection,  its  application  first 
signals  to  the  server  and  then  sends  session  description  objects  that  contain 
parameters  and  Internet  information  to  the  browser  for  setting  up  the  peer-to- 
peer  route.  Figure  1  describes  the  technique  of  making  peer-to-peer  connections 
between  browsers.  WebRTC  allows  users  using  any  mechanism,  protocol,  or 
even  JSON  to  make  connections  to  maximize  compatibility  with  established 
technologies,  which  is  defined  by  JavaScript  session  establishment  protocol 
(JSEP)  (Dutton,  2013). 
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Figure  1.  JSEP  architecture(from  Dutton,  2013). 


RTCDataChannel  is  a  bidirectional  communication  of  arbitrary  data 
between  peers,  and  all  the  data  is  encrypted  by  Datagram  Transport  Layer 
Security  (DTLS),  which  is  a  derivative  of  SSL.  RTCDataChannel  is  much  like  a 
WebSocket,  but  it  relies  on  the  Stream  Control  Transmission  Protocol  (SCTP), 
which  runs  on  top  of  the  UDP  socket.  A  comparison  of  TCP,  UDP,  and  SCTP  is 
in  Table  1.  Based  on  the  features  of  SCTP,  RTCDATAChannel  is  suitable  for 
arbitrary  data  transfer  or  multiplayer  gaming. 


TCP 

JDP 

SCTP 

Reliability 

reliable 

jnreliiable 

configurable 

Delivery 

ordered 

j  reordered 

configurable 

Transmission 

byte-oriented 

message -oriented 

message-oriented 

Flow  ccntro 

yss 

lO 

yes 

Congestion 

control 

yss 

no 

yes 

Table  1.  TCP,  UDP,  and  SCTP  comparison  (from  Ristic,  2014). 
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6. 


WebGL 


Web  graphics  library  (WebGL)  is  a  JavaScript  API  for  rendering  2D  or  3D 
graphics  in  any  compatible  browser  (i.e. ,  most  modern  browsers  such  as  IE 
vll.O,  Opera  v23.0,  Chrome  v36.0,  Firefox  v31,  or  Safari  v7)  (Deveria,  n.d.-a). 
WebGL  can  be  used  for  processing  2D  images,  creating  visually  3D  graphics  and 
visualizing  different  kinds  of  data.  For  example,  D3.js  is  a  JavaScript  API  that 
visualizes  varieties  of  data  in  browsers  by  using  HTML,  SVG,  and  CSS.  Many 
WebGL  libraries  are  game  engines  for  rendering  graphics  in  browsers;  these 
include  pixi.js,  Phaser,  and  three.js.  WebGL  provides  the  web  pages  with  the 
capability  of  efficiently  creating  interactive  2D  and  3D  graphics  to  simulate 
objects  in  web-based  simulations. 

7.  JSON  DIS  Format 

JavaScript  Object  Notation  (JSON)  is  a  text-data  format  that  facilitates 
data  interchange  between  different  languages  (“JSON,”  n.d.).  The  purpose  of 
JSON  is  to  store  and  exchange  text  information.  It  is  like  XML,  but  smaller,  faster, 
and  easier  to  parse.  JSON  is  used  to  describe  data  objects  not  only  for 
JavaScript,  but  also  for  other  programming  languages.  It  is  language- 
independent  because  most  of  the  programming  languages  have  their  own 
methods  and  libraries  to  parse  JSON  text.  JSON  and  JavaScript  syntactically  use 
the  same  method  to  describe  objects,  so  when  JavaScript  receives  JSON  format 
files,  JavaScript  uses  a  built-in  eval()  function  to  generate  JavaScript  objects. 
JSON  format  is  based  on  two  kinds  of  structure:  pairs  of  name  and  value,  and 
ordered  lists.  Pairs  of  name  and  value  is  similar  to  object,  record,  struct, 
dictionary,  hash  table,  keyed  list,  or  associative  array  in  other  languages. 
Ordered  list  is  like  array  in  other  languages. 

DIS  protocol  can  be  formatted  in  the  form  of  JSON,  which  uses  a  tag- 
value  approach  to  make  JavaScript  objects  containing  PDU  information.  This  DIS 
JSON  can  be  sent  by  WebSocket  or  WebRTC  API  after  invoking  JSON.stringify(), 
a  JavaScript  method,  to  convert  a  JavaScript  object  to  JSON.  Another  browser 
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can  receive  this  DIS  JSON  and  decode  as  a  JavaScript  object.  Although  JSON 
exchanges  data  well,  it  has  some  inevitable  drawbacks.  JavaScript  object  uses  a 
tag-value  approach,  so  both  publisher  and  subscriber  must  have  agreement 
regarding  field  names  in  the  messages.  This  feature  increases  the  flexibility  of 
creating  objects,  but  it  uses  more  bandwidth  in  messages. 

8.  Binary  DIS  Format 

DIS  protocol  has  been  approved  by  IEEE,  and  it  is  widely  used  in  many 
existing  simulation  applications.  Using  binary  format  to  exchange  messages 
between  browsers  has  a  better  performance  than  JSON.  Not  only  the  message 
size  in  DIS  binary  is  smaller  than  JSON  with  full  DIS  messages,  but  also  the 
decoding  speed  in  DIS  binary  is  faster  than  JSON  messages  (McGregor  et  al., 
n.d.).  Another  advantage  of  binary  DIS  format  is  that  DIS  is  a  standardized 
protocol,  and  using  it  eliminates  the  intermediary  gateways  for  protocol 
translation.  Additionally,  many  existing  gateways  convert  different  protocols  into 
DIS  protocol  such  as  JBUS — Joint  Simulation  Bus — and  this  increases  the 
interoperability  between  existing  simulation  systems  and  web-based  simulations. 

Using  the  above  elements — which  included  networking,  DIS  protocol, 
programming  language,  web  server  with  specialized  TCP  socket,  WebRTC,  3D 
graphics,  and  DIS  JSON  formatting  or  binary  formatting  message — it  is  possible 
to  create  an  interactive  web-based  simulation  with  human-in-the-loop  features. 
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III.  EXPERIMENTAL  DESIGN 


To  understand  the  performance  of  running  DIS  in  browsers,  this  thesis 
created  an  experimental  design  with  several  variables  that  included  networking 
framework  (WebSocket  and  WebRTC),  application  of  WebGL  and  different 
browsers.  The  experimental  devices  included  a  wired  router,  two  desktop 
computers  as  clients  and  one  laptop  computer  as  WebSocket  server  and 
WebRTC  server.  The  specifications  of  the  two  desktop  computers  are  as  follow: 
Intel®  Xeon®  CPU  E5-1603  0  @  2.8  GHz,  6  GB  memory,  NVIDIA  Quadro  4000 
graphics  card,  and  Windows  7  64-bit  operating  system.  The  specifications  of  the 
server  are  as  follow:  Intel®  Core™2  Duo  CPU  L9400  @  1 .86  GHz,  2  GB  memory, 
NVIDIA  GeForce  320  M  graphics  card  and  Windows  7  32-bit  operating  system. 

A.  NETWORKING  FRAMEWORK 

There  are  many  ways  to  make  communication  among  computers,  such  as 
client-server  architecture  or  peer-to-peer  architecture.  Because  of  the  emergence 
of  web  technologies  (WebSocket  and  WebRTC),  many  networking  architectures 
can  be  applied  to  web-based  applications. 

1 .  Client-Server  Architecture  (WebSocket) 

WebSocket  is  a  TCP-based  socket,  which  means  it  has  all  the  features  of 
TCP  socket  such  as  reliable  and  ordered  data  interchange,  and  it  can  be  used  to 
transport  arbitrary  data  type  for  different  web  applications. 

a.  Open-DIS  WebSocket  Gateway  Server 

Open-DIS  is  an  open-source  implementation  of  the  DIS  protocol  in  many 
languages  (McGregor,  Grant,  Smith,  Harder  &  Snyder,  n.d.).  It  was  developed 
mainly  by  the  Modeling,  Virtual  Environment,  and  Simulation  (MOVES)  Institute 
at  the  Naval  Postgraduate  School.  From  the  Open-DIS  official  website,  users 
can  download  a  “javascript.zip”  archive  to  obtain  WebSocket  gateway  server. 
The  archive  has  example  applications  including  sending  and  receiving  native  DIS 
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messages  and  WebSocket/Javascript/WebGL  applications.  For  this  experiment, 
the  WebSocket  application  was  run  in  NetBeans,  which  is  a  free  integrated 
development  environment  (IDE)  for  developing  desktop,  mobile  and  web 
applications  with  JAVA,  C++,  HTML5,  JavaScript  and  more. 

b.  Framework 

The  DIS  implementation  of  WebSocket  gateway  server  is  client-server 
architecture,  shown  in  Figure  2.  Every  DIS  message  that  is  sent  from  the  web 
browser  must  go  through  the  WebSocket  gateway  server.  The  server  will  repeat 
received  DIS  messages  to  all  connected  web  browsers.  Because  all  the  client 
browsers  are  connected  to  the  server,  the  server  plays  a  vital  role  in  a  client- 
server  web-based  simulation.  If  the  server  loses  its  networking  connection,  all  the 
browsers  will  lose  their  ability  to  interoperate,  and  then  the  web-based  simulation 
will  become  a  single-player  game  or  crash. 


Figure  2.  WebSocket  networking  framework. 


2.  Peer-to-Peer  Architecture  (WebRTC) 

Unlike  the  WebSocket,  WebRTC  uses  UDP  sockets  that  have  no  flow 
control  and  no  congestion  control.  They  are  also  unreliable  and  offer  unordered 
data  exchange  to  transfer  data.  The  WebRTC  data  channel,  however,  uses 
SCTP — which  is  a  protocol  on  top  of  the  UDP  sockets — to  configure  data 
reliability  and  to  order  and  control  data  flow  and  congestion.  The  networking 
architecture  of  WebRTC  is  like  a  peer-to-peer  with  rendezvous  server  model. 
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a.  PeerJS 

PeerJS  is  an  application  programming  interface  (API)  based  on  WebRTC 
(Bu  &  Zhang,  n.d.).  It  wraps  WebRTC  implementation  and  provides  a  fully 
documented  and  easily  configurable  API  for  developers  to  create  peer-to-peer 
connections  in  web  browsers  with  nothing  but  a  unique  ID.  Client  browser 
creates  a  unique  ID  and  connects  to  PeerServer,  and  the  server  uses  this  ID  to 
identify  and  deliver  connection  information  to  the  prospective  peers.  The  ID  is 
formed  with  numbers  and  letters.  If  a  client  browser  connects  to  a  PeerServer 
without  a  unique  ID,  the  PeerServer  would  create  an  ID  for  this  active  client.  If  a 
client-browser  connects  to  a  PeerServer  with  an  ID  that  has  been  used  for  other 
client  browser,  this  client  would  connect  as  failed,  and  the  server  would  respond 
with  error  messages  to  the  client. 

On  each  connection  between  a  pair  of  browsers,  audio,  video,  and 
arbitrary  data  can  be  sent.  Although  WebRTC  is  peer-to-peer  connections,  the 
client’s  browser  must  first  signal  to  a  PeerJS  server  to  get  connection  information 
that  is  based  on  a  session  description  protocol  (SDP).  WebRTC  uses  SDP  to 
describe  a  session  profile,  which  contains  information  such  as  transportation 
address,  media  information,  and  related  metadata.  Browsers  use  this  session 
profile  to  create  peer  connections.  PeerJS  provides  PeerServer  on  Cloud,  a 
public  server  that  everyone  can  use  by  registration  on  the  PeerJS  Website,  and 
PeerServer  application  for  installation  in  a  private  network. 

b.  Framework 

This  thesis  used  PeerJS  to  create  a  data  channel  to  interchange  DIS 
messages  between  peers.  The  framework  is  in  Figure  3.  Before  a  peer-to-peer 
connection,  each  peer  has  to  initially  connect  to  a  PeerServer  to  get  another 
peer’s  information  and  a  web  server  to  receive  web  content.  Once  the  peer 
browsers  construct  data  channels  and  receive  web  content,  the  peers  no  longer 
need  the  PeerServer. 
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Figure  3.  WebRTC  networking  framework. 


B.  PERFORMANCE  WITH  WEBGL 

WebGL  is  one  of  the  critical  elements  in  web-based  simulation.  Users  feel 
more  immersed  if  a  simulation  has  lifelike  models,  especially  3D  models  in  a  vivid 
virtual  environment.  Running  3D  graphics,  however,  is  resource  consuming, 
which  means  computers  have  to  devote  lots  of  CPU  or  GPU  resources  to 
computing  the  change  of  3D  graphics  (e.g.,  movement,  scaling,  rotation). 
Therefore,  this  thesis  designed  a  comparison  for  applying  WebGL  or  not.  All  the 
experimental  3D  models  were  made  with  Blender,  which  is  free  and  open-source 
software  for  computer  3D  graphics.  Blender  has  an  add-on  function  to  export  3D 
graphics,  and  a  library  implemented  WebGL  (three.js),  which  has  loaders  for 
importing  .js  models  into  web  pages. 

1.  Without  WebGL  Elements 

Purely  DIS  messages  send  and  receive  without  WebGL  elements  in 
different  networking  frameworks.  In  order  to  find  out  the  capability  of  sending  and 
receiving  speed  in  modern  browsers,  two  browsers  were  opened  on  two 
computers  with  the  same  hardware  devices;  one  was  for  sending  DIS  packets 
and  the  other  was  for  receiving  DIS  packets.  The  sending  browser  repeatedly 
converted  an  ESPDU  JavaScript  object  to  binary  format  DIS  messages  before 
sending  those  messages.  The  receiving  browser  decoded  the  binary  message, 
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converted  it  a  JavaScript  object  and  distinguished  PDU  types  every  time  it 
received  DIS  messages. 

2.  With  WebGL  Elements 

WebGL  enables  web  browsers  to  render  3D  graphics  without  plugins,  but 
it  also  takes  a  lot  of  computational  resources.  This  thesis  created  a 
demonstrating  game  that  used  WebGL  and  the  three.js  library  to  render  3D 
graphics  and  DIS  PDUs  to  exchange  entity  information. 

a.  3D  Models 

This  thesis  designed  three  major  3D  models  (terrain,  tank  and  tank 
ammunition)  to  demonstrate  the  feasibility  of  web-based  simulation.  The 
demonstration  was  a  simple  and  first-person-shooter  tank  game.  The  players 
controlled  a  single  tank  to  search,  aim,  and  shoot  other  tanks  in  a  virtual 
environment  in  a  web  browser.  This  game  was  designed  for  multiple  players. 
Each  player,  and  each  browser  page,  created  its  own  virtual  environment 
(including  scene,  skybox,  light,  camera,  terrain,  a  controllable  tank,  tank 
ammunition,  etc.)  when  the  browser  connected  to  a  web  server  and  got  the  game 
html  file.  Browsers  started  sending  and  receiving  DIS  messages  once  they 
connected  to  a  WebSocket  gateway  server  or  established  a  WebRTC  data 
channel.  Other  tank  models  and  ammunition  models  were  created  when  a 
browser  received  ESPDUs  whose  entity  IDs  were  new  to  that  browser,  which 
meant  that  each  opponent  tank  model  had  a  corresponding  entity  ID.  If  an 
incoming  ESPDU’s  entity  ID  already  had  a  representative  3D  object,  the  browser 
would  update  the  state  and  location  of  this  3D  object  in  the  virtual  world. 

b.  Game  Design 

There  are  three  different  types  of  DIS  PDUs  in  this  tank  game:  entity  state 
PDU  (ESPDU),  collision  PDU  and  fire  PDU.  Figure  4  describes  the  mechanism  of 
this  tank  game.  The  upper  section  is  about  sending  DIS  PDUs,  and  the  lower 
describes  receiving  DIS  PDUs.  When  the  game  started  and  a  controllable  tank 
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was  created  in  the  scene,  the  tank  could  move  and  search  for  targets.  At  the 
same  time,  the  tank  issued  ESPDUs  every  ten  milliseconds,  which  was  the  same 
rate  at  which  WebGL  updated  its  canvas. 

The  ESPDUs  are  the  major  interchanging  PDUs  in  DIS  simulations,  and 
contain  all  the  basic  information  of  entities  (e.g.,  entity  ID,  entity  type,  entity 
location,  and  entity  orientation).  The  collision  PDU  contains  information  about 
collision  events,  and  is  issued  when  a  collision  happens  between  two  simulated 
entities  or  between  a  simulated  entity  and  another  object  in  the  virtual  world.  In 
this  tank  game,  a  collision  PDU  was  issued  only  when  a  tank’s  projectile  hit 
another  tank.  The  fire  PDU  is  used  to  support  visual,  aural,  and  other  effects,  and 
identify  an  entity  that  fired  a  weapon  or  expendable.  The  fire  PDU  in  this  game, 
however,  was  only  used  to  communicate  firing  events  and  showed  the  firing 
information  on  screen. 

To  play  this  game,  the  player  has  to  eliminate  all  other  tanks  in  the  virtual 
battlefield.  If  a  tank  gets  hit  while  searching  for  targets,  it  will  issue  a  collision 
PDU.  The  information  in  a  collision  PDU  includes  the  issuing  entity  ID,  colliding 
entity  ID,  event  ID,  location,  etc.  If  a  tank  finds  a  target  and  shoots  it,  the  tank  will 
issue  a  fire  PDU  regardless  of  whether  it  hits  its  target.  A  fire  PDU  contains  the 
fields  firing  entity  ID,  target  entity  ID,  location,  etc.  for  describing  the  firing  event. 
If  a  tank  hits  a  target,  the  tank’s  projectile  will  issue  a  collision  PDU.  In  the 
receiving  section,  when  the  browser  receives  a  DIS  message,  the  message  will 
be  decoded  and  categorized  into  ESPDU,  collision  PDU  or  fire  PDU.  If  a  browser 
receives  an  ESPDU  and  the  ESPDU’s  entity  ID  is  new  to  this  browser,  the 
browser  loads  a  3D  object  to  represent  this  entity  ID.  Otherwise,  the  browser 
updates  the  state  and  location  of  this  3D  object.  If  browsers  receive  fire  PDUs, 
they  display  the  fire  information  in  the  upper-left  corner  of  the  window.  If  a 
browser  receives  a  collision  PDU,  it  checks  whether  its  controllable  tank  issued  a 
collision  PDU  within  two  seconds  (a  game  setting).  If  the  answer  is  yes,  the  tank 
is  killed,  and  the  game  is  over.  If  no,  there  might  be  some  latency  or  lag  in 
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networking  traffic  that  created  an  asynchronous  situation,  so  the  game  would 
continue. 


Figure  4.  Tank  game  design. 


C.  PERFORMANCE  IN  DIFFERENT  BROWSERS 

Modern  browsers  such  as  Chrome,  Firefox,  and  Safari  use  different 
JavaScript  engines  to  execute  JavaScript.  Chrome  uses  V8  as  its  JavaScript 
engine.  V8  is  an  open-source  and  high-performance  JavaScript  engine  that  is 
written  in  C++  and  implements  ECMAScript  as  specified  in  ECMA-262,  5th 
Edition  (“Chrome  V8,”  n.d.).  V8  can  be  run  on  most  modern  operating  systems 
such  as  Windows  (XP  or  newer),  Mac  OS  X  (10.5  or  newer)  and  Linux  systems. 
Firefox’s  JavaScript  engine  is  called  SpiderMonkey,  which  is  written  in  C/C++ 
(“Firefox  SpiderMonkey,”  n.d.).  The  latest  JavaScript  just-in-time  (JIT)  compiler 
for  SpiderMonkey  is  called  lonMonkey,  which  is  implemented  in  the  latest  Firefox 
browser  and  can  be  installed  in  most  modern  operating  systems.  Safari  uses 
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another  JavaScript  engine  Nitro,  but  this  thesis  did  not  use  Safari  for  experiments 
because  Safari  does  not  support  WebRTC  yet. 

Different  JavaScript  engines  cause  variations  in  browser  performance. 
There  are  many  web  applications  for  benchmarking  JavaScript  performance 
among  different  versions  of  browsers  or  different  brands  of  browsers,  including 
SunSpider,  Kraken,  and  Octane.  The  benchmarking  tests  are  varied,  and  it  is 
hard  to  measure  the  performance  precisely  because  there  are  too  many 
variables  (e.g.,  CPU,  memory,  browser  version)  to  affect  the  benchmarking 
results.  The  common  benchmarking  tests  include  OS  kernel  simulation 
benchmark,  3D  ray  tracer,  cryptography  test,  code  decompression,  PDF  reader 
implementation,  etc.  There  is  an  existing  website  showing  benchmarking 
comparisons  between  modern  browsers  within  different  operating  systems,  and 
the  website  visually  displays  the  differences  among  those  modern  browsers 
(“Arewefastyet,”  n.d.). 

Currently,  WebSocket  is  supported  widely  by  almost  every  browser 
(Deveria,  n.d.-c).  WebRTC  is  supported  by  a  few  browsers,  including  Chrome, 
Firefox,  and  Opera.  The  global  usage  of  Chrome,  Firefox  and  Opera  is  28.39%, 
4.69%  and  0.36%,  respectively  (Deveria,  n.d.-b).  Therefore,  the  comparison  of 
performance  between  browsers  mainly  focuses  on  Chrome  and  Firefox  in  this 
thesis. 
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IV.  IMPLEMENTATION 


In  order  to  implement  experiments,  four  services  were  run  on  the  server 
side:  WebSocket  gateway,  web  service,  PeerServer  and  primary  peer.  The 
experimental  environment  can  be  divided  into  two  parts:  WebSocket  and 
WebRTC.  This  thesis,  however,  used  one  computer  to  run  these  four  services. 
Figure  5  shows  the  experimental  environment  for  this  thesis.  The  first  part  was 
client-server  framework  using  WebSocket  gateway  server.  The  server,  which 
was  downloaded  from  the  Open-DIS  project  website,  provides  web  server  and 
server-side  implementation  of  WebSocket. 

Second  part  was  peer-to-peer  framework  using  PeerServer.  PeerServer 
only  has  the  capability  to  help  broker  connections  between  peers,  so  the 
experiments  in  this  thesis  used  the  web  server  from  WebSocket  gateway  server 
for  users  to  download  web  content,  WebGL  elements,  3D  models  and  JavaScript 
code.  One  of  the  features  of  PeerJS  is  using  unique  IDs  to  make  peer 
connections,  so  the  newly-joined  peer  has  to  obtain  the  IDs  of  others  to  create 
peer  connections  beforehand.  The  primary  peer  was  a  webpage  that  collected 
the  peer  IDs  and  distributed  a  list  of  live  peers  to  all  connected  peers.  Although 
every  client  has  a  data  channel  with  the  primary  peer,  they  would  not  send  any 
DIS  packets  to  the  primary  peer.  A  connected  peer  list  was  the  only  distributed 
data  under  this  data  channel. 
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A.  SERVER  PREPARATIONS 

The  following  section  describes  preparatory  works  for  the  above- 
mentioned  four  services  that  were  used  to  support  the  performance  tests  in  this 
thesis. 


1 .  WebSocket  Gateway  Server  and  Web  Server 

WebSocket  gateway  server  ran  on  a  computer  with  NetBeans  installed. 
This  server  also  had  the  capability  of  web  server,  so  clients  could  get  web 
content  from  a  server  IP  address  on  port  8282.  Port  8282  is  a  default  setting  for 
this  server.  This  server  also  can  receive  native  DIS  messages  that  were 
broadcast  from  other  simulation  systems  using  UDP  socket  with  port  3000,  but 
this  function  was  turned  off  manually  in  the  experiments.  The  WebSocket  was 
client-server  architecture,  so  the  expression  in  Figure  5  was  that  Client  A  sent 
DIS  messages  to  WebSocket  gateway  server  and  then  the  server  distributed  the 
receiving  DIS  messages  to  Client  B,  and  vice  versa. 
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2.  WebRTC:  PeerServer  and  Primary  Peer 

PeerServer  is  Node.js-based  application,  so  the  server  computer  must 
install  Node.js  before  running  PeerServer.  Node.js  is  a  V8  (JavaScript  engine) 
based  platform  for  developing  fast  and  scalable  network  applications.  Figure  6 
shows  how  to  install  and  execute  PeerServer  after  having  Node.js  installed. 
Node.js  can  be  obtained  from  its  official  website:  http://nodejs.org/.  PeerServer 
used  port  9000  to  help  broker  connections  between  peers.  The  primary  peer  was 
one  of  PeerServer  clients,  so  the  primary  peer  could  be  executed  after 
PeerServer  was  on.  WebRTC  is  peer-to-peer  connection  with  a  rendezvous 
server;  the  framework  is  shown  in  Figure  3. 
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Figure  6.  Install  and  execute  PeerServer. 

B.  BROWSER  INITIATIVE  PROCESSES  AND  BEHAVIORS 

Once  the  server  and  services  were  established,  client  browsers  could 
connect  to  the  server  to  receive  web  contents.  The  web  contents  helped  the 
browsers  initiate  a  virtual  world  inside  the  window  and  interact  with  users.  The 
initiative  processes  included  importing  necessary  libraries;  checking  browser 
brands,  and  creating  a  canvas,  scene,  virtual  objects,  etc.  Once  the  browser  was 
initiated,  it  began  sending  and  receiving  DIS  PDUs  via  WebSocket  or  WebRTC 
data  channels.  At  the  same  time,  the  browser  was  ready  to  interact  with  users  via 
the  computer  keyboard.  The  following  describes  the  processes  of  initiating  web 
browsers  and  the  behaviors  of  exchanging  DIS  packets  and  interacting  with 
users. 
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1.  Import  Libraries 

The  “dis.js”  archive  is  an  essential  library  for  experiments  in  this  thesis, 
and  it  can  be  downloaded  from  the  Open-DIS  project.  It  includes  all  DIS  PDU 
classes  and  methods  that  convert  from  DIS  PDU  objects  into  binary  format  DIS 
and  vice  versa. 

a.  WebSocket 

WebSocket  is  a  native  capability  in  web  browsers  that  support  WebSocket, 
so  no  specific  library  needs  to  be  imported  for  WebSocket. 

b.  WebRTC 

WebRTC  is  included  in  the  web  browser,  and  PeerJS  wraps  the  browser’s 
WebRTC  implementation.  This  thesis  used  PeerJS  as  an  API  to  create 
WebRTC  data  channels,  so  the  “peer.js”  library  obtained  from  the  PeerJS 
official  website  must  be  imported  at  the  beginning. 

c.  WebGL 

WebGL  is  native  in  browser.  This  thesis  applied  “three.js,”  which  is  layered 
on  top  of  WebGL  as  a  library  for  3D  graphics  in  web  browsers  (Parisi,  2012).  It 
can  be  used  to  create  scene  graphs,  camera,  light,  skybox,  and  basic  3D 
graphics,  and  it  also  can  manipulate  imported  3D  models  by  applying  different 
materials  or  shaders. 

d.  Others 

Other  libraries  included  OrbitControls.js  as  well  as  various  loader  and  self- 
defined  js  archives.  OrbitControls.js  was  used  to  control  the  camera  by  mouse  in 
browsers,  and  the  different  loaders  were  for  loading  different  formats  of  3D 
models  such  as  obj,  js,  mtl,  and  max.  Figure  7  shows  the  relationships  of 
importing  libraries  and  other  JavaScript  programs. 
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Figure  7.  Relationships  of  importing  libraries  and  other  JavaScript  programs. 

2.  Checking  Web  Browser  Brand  and  Initiating  WebSocket  or 

WebRTC 

Different  browsers  have  different  engines  to  implement  JavaScript,  so 
when  an  end  user  downloads  web  content  from  a  web  server,  JavaScript  code 
must  check  what  kind  of  browser  is  being  used.  WebSocket  and  PeerJS  that 
implements  WebRTC  have  different  ways  to  check  browser  brands. 

a.  WebSocket 

WebSocket  is  widely  supported  by  many  browsers.  The  main  browsers 
this  thesis  had  to  differentiate  were  Chrome  and  Firefox.  Figure  8  shows  the 
JavaScript  code  for  distinguishing  browser  brands  and  establishing  a  connection 
to  the  server. 

if(  window.  WebSocket) 

websocket  =  new  WebSocket("ws://websocket.example.com:8282"); 

else  if(Window.MozWebSocket) 

websocket  =  new  MozWebSocket("ws://websocket. example. com:8282"); 

else 

alertf'This  web  browser  does  not  support  web  sockets"); 

Figure  8.  Creating  WebSocket  code. 
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WebRTC 


b. 

The  WebRTC  is  wrapped  by  the  PeerJS  API,  and  it  automatically  checks 
browsers  for  web  application  developers.  To  initiate  a  peer  object,  a  user  has  to 
randomly  produce  a  peer  ID  to  signal  to  the  PeerServer,  and  then  wait  for  a 
connection  from  other  peers.  If  the  ID  is  not  given,  the  PeerServer  will  generate 
one  for  this  client.  Figure  9  shows  the  code  for  creating  a  peer  object  and 
signaling  to  PeerServer. 

peer  =  new  Peer(  peerlD,  {host:  PeerServer.example.com,  port:  9000 }); 

Figure  9.  Initiate  a  PeerJS  client. 

There  are  two  situations  for  creating  peer  connections:  pre-known  the  ID 
of  prospective  peer  and  unknown  the  ID  of  prospective  peer.  Figure  10  shows 
the  architecture  and  sequence  of  creating  connections  among  peers  for 
performance  tests  in  this  thesis.  The  following  three  steps  describe  the 
mechanism  of  creating  peer  connections  in  the  situation  of  an  unknown 
prospective  peer  ID.  This  thesis  uses  the  primary  peer  to  help  distribute  an  ID  list 
to  all  connected  peers.  If  the  peer  ID,  however,  is  pre-known,  a  peer  can  create  a 
peer  connection  to  another  peer  directly  with  the  help  of  PeerServer.  For 
example,  in  Figure  10  the  game  client  A  creates  a  peer  connection  to  primary 
peer  because  client  A  has  known  the  ID  of  primary  peer  beforehand.  Only  the 
following  step  1  and  step  2  are  involved  in  this  case. 

Step  1 :  The  primary  peer  maintains  a  list  of  all  the  peers  connected  in  the 
tank  game.  It  must  be  running  before  any  game  clients  start.  When  game  clients 
begin  execution,  they  contact  the  primary  peer  and  provide  their  IDs.  The 
Primary  Peer  in  turn  informs  the  game  clients  of  the  IDs  of  other  peers.  This 
allows  the  game  clients  to  establish  pair-wise  connections  for  communication. 

Step  2:  When  the  first  game  client  starts,  it  first  contacts  the  PeerServer  to 
get  the  information  necessary  to  establish  a  connection  to  the  Primary  Peer.  It 

then  connects  the  Primary  Peer  and  provides  its  ID. 
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Step  3:  When  a  second  game  client  starts  it  also  first  contacts  the  Peer 
Server  as  the  first  step  for  contacting  the  Primary  Peer.  It  contacts  the  Primary 
Peer  and  provides  its  ID,  and  is  in  turn  informed  of  the  IDs  of  all  other  game 
clients.  Any  other  game  clients  are  informed  of  the  ID  of  the  new  game  client.  All 
game  clients  can  then  establish  pairwise  connections  between  each  other.  The 
tank  game  client  A  established  a  WebRTC  connection  to  game  client  B,  and 
game  client  B  establishes  a  connection  to  game  client  A. 

In  reality,  each  connection  is  a  bidirectional  channel.  For  example,  if  client 
A  established  a  connection  with  client  B,  client  B  could  use  this  connection  to 
exchange  data  with  client  A.  This  thesis,  however,  constructed  two  data  channels 
between  each  pair  of  clients  for  convenient  configurations  of  sending  and 
receiving  behaviors. 


Cresting  peer  connections 
<r- - > 


Figure  10.  Architecture  and  sequences  of  creating  peer  connections. 
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3.  Create  Canvas,  Scene,  Camera,  and  Own  Entities 

HTML5  has  a  “canvas”  element  for  drawing  2D  and  3D  graphics  on  web 
pages,  and  the  three.js  library  provides  methods  to  create  and  display  animated 
3D  computer  graphics  on  browsers  that  support  WebGL.  Figure  1 1  shows  the 
codes  to  create  a  canvas  and  Figure  12  shows  the  basic  elements  in  the  scene. 
Every  computer  graphical  elements — such  as  3D  graphics,  light  and  camera — 
were  added  into  the  scene  in  the  tank  game. 

At  the  same  time,  a  controllable  tank  model  was  loaded  by  the  JSON 
loader  after  the  scene  was  created,  and  two  JavaScript  objects  were  created. 
One  was  to  contain  this  controllable  tank  and  an  ESPDU  that  represents  the 
states  of  this  tank.  Another  object  comprised  a  tank’s  ammunition  mesh  and  a 
different  ESPDU  that  restored  information  of  this  ammunition.  Figure  13  shows 
codes  of  JavaScript  objects  that  contained  the  tank  object  and  its  corresponding 
ESPDU.  It  also  shows  some  numbers  were  assigned  in  the  field  of  entity  type. 
These  numbers  were  used  to  identify  military  hardware,  and  they  referred  to  a 
SISO  document  called  the  “Enumeration  and  Bit  Encode  Values”  (EBV).  The 
EBV  document  is  a  long  listing  of  standardized  enumeration  for  simulation 
interoperability  ( Simulation  Interoperability  Standards  Organization  (SISO) 
Reference  for:  Enumerations  for  Simulation  Interoperability,  2013). 


<body> 

<div  id="container"> 

<canvas  style="width:100%;height:95%;border:lpxgray  solid;"> 


</div> 

</body> 


Figure  1 1 .  Creating  canvas  in  a  web  page. 
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var  mycanvas  =  document. getElementsByTagName("canvas")[0]; 

var  w  =  mycanvas. clientWidth; 

var  h  =  mycanvas.clientHeight; 

scene  =  newTHREE.Scene(); 

camera  =  newTHREE.PerspectiveCamera( 

30,  // Field  of  view 

w/h,  //Aspect  ratio 
0.1,  //Near 
10000  //Far 
); 

scene.add(camera); 

var  light  =  new  THREE. PointLi ght(  OxFFFFFF  ); 
scene.add(  light ); 

var  ambient  =  new  THREE. AmbientLight(  0x222222  ); 
scene. add(  ambient ); 

Figure  12.  Creating  scenes  and  adding  graphical  elements. 


var  ourEntity=  {}; 

var  loader  =  new  THREE.JSONLoader(); 
ourEntity.tank-  new  Tank(ioader); 
ourEntity.lastEspdu  =  new  dis.EntityStatePdu(); 
ourEntity.lastEspdu.entityType.entityKind  =  1;  //Platform 
ourEntity.lastEspdu.entityType. domain  =  1;  //Land 

ourEntity.lastEspdu.entityType. country^  225;  //U.S. 

ourEntity.lastEspdu.entityType. category  =  1; 
ourEntity.lastEspdu.entityType. subcategory  =  1; 
ourEntity.lastEspdu. entityType. spec  =  3; 

ourEntity.lastEspdu.entitylD.entity=  Math.round(Math.random()  *  20000); 

Figure  13.  Creating  tank  meshes  and  ESPDUs  in  ourEntity  objects. 

4.  Game  Control  and  Graphics  Rendering 

Human-in-the-loop  simulations  must  contain  input  devices  for  users  to 
give  orders,  and  all  the  web  applications  are  run  on  computers  and  mobile 
devices.  The  development  of  this  thesis’s  demonstration  was  based  on  using  the 
keyboard  and  mouse  as  input  devices.  Players  used  the  keyboard  to  control  the 
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tank,  fire  missiles,  and  switch  cameras;  they  used  the  mouse  to  change  player 
perspective  views.  JavaScript  provides  corresponding  key  codes  that  are 
associated  with  keyboard  characters  for  web  application  developers  to  develop 
different  functions  in  different  keys  (Lautenschlager,  n.d.).  JavaScript  also 
provides  event  handlers  for  keydown  and  keyup  events  in  the  window.  The 
example  tank  game  used  keys  “W”  and  ”S”  to  move  the  tank  forward  and 
backward,  keys  “A”  and  “D”  to  turn  the  tank  left  and  right,  keys  “Q”  and  “E”  to 
adjust  the  tank’s  barrel,  key  “Space”  to  fire  a  missile,  and  keys  “1”  and  “2”  to 
switch  cameras.  Figures  14  and  15  show  examples  of  using  JavaScript  key 
codes  to  program  different  actions. 


Fun  til  Oil  ?=nfi^yDywn(Hvt; 

( 

iWitcti  levt.keyCode. 

[ 

case  ^-9;  //I '//camera! 

camera  “  fameral;  break, 
caseEO:  //'21  //camera 2 

camera  -  camera?;  hreak; 
case  65: //'a1 

ou  rE  ntity.tn  n  k.  rotation  5p  ee  ri  -  +1.0;  break; 
case  68;  //rd' 

ou r Entity. tan k„rotation.3p ced  -  1.0,  bnca^ 
case  67:  //  'w' 

CiurEnr<iv.[arik.irafTSlat^on5pped^  +10.0;  break, 
case  £3:  //'s' 

OUrEn^hy.t^nk.tran.slation Speeds  -  IC  O;  break; 
case  £1 :  // 1  q 1  f/e I  ewate  barre  I 

ourEntd^Uank.e'evateSpeed^  0  5;  break; 
case  69;  //  reJ  //elevate 

ourEntity.tank,e;evDteSpeed=  -0.5;  break; 
rase  ^2'  //  spacebar  //Fire 

r{ourM  u  n  i:i  o  n  E  itity.munftion .  missile  Rea  d  v  ForSfrooEmg] 

[ 

munltilonFIre  -  true; 

mu  r  i  i  Liui  i5t:i  lUCul  I  i  si  u  1 1  Pd  u  =  Lr  ur : 
ourML.nitiQnEnlity.muniticHi.rrtteile5ho-ot  -  irue; 

}bre  at; 

I 


Figure  14.  Function  of  keydown  events. 
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function  onKeyUpfevt) 

{ 

switch  (evt-keyCode) 

I 

case  6E:  if  'a' 

ourEntity.ta  n  k.  rotati  on  Spee  d  =  0.  Q;  break; 
case  ss;  if  'd' 

ourEntity,tank.  rotation  Speed  =  0.0;  break; 
case  87:  If  'w' 

ourE  ntity.ta  n  k.  tra  nil  atTonSpeed  =  0.D;  break; 
case  83;  if  V 

aurEntity.tank.translationSpeed  -  0.0;  break; 
case  81;  if  q' 

ourEntity.tank. elevateS peed  -  0.0;  break; 
case  bb:  if  'e' 

ourEntity.tank. elevateS peed  ^  0.0;  break; 

I 

}; 

wi  n  dow.  c  n  keydown  =  g  n  Key  D  own ; 
window,  on  key  up  =  on  Key  Up; 


Figure  1 5.  Function  of  keyup  events  and  window  event  handlers. 


The  frequency  of  rendering  3D  graphics  affects  the  fluidity  of  the  game. 
Most  video  games  use  30  frames  per  second  (fps)  or  60  fps  and  some,  such  as 
Halo3,  are  locked  at  30  fps  maximum  (“Frame  rate,”  n.d.).  JavaScript  provides  a 
setlnterval  method  that  repeatedly  calls  a  function  in  a  specific  interval.  In  the 
tank  game,  the  rendering  frequency  was  set  to  ten  milliseconds,  which  equals  to 
100  fps,  and  all  the  game  events  and  animations  were  based  on  that  timestamp. 

5.  Convert  Coordinate  Systems 

The  DIS  uses  the  ECEF  (Earth-centered,  Earth-fixed)  coordinate  system, 
which  defines  point  (0,  0,  0)  as  the  center  of  the  earth.  The  positive  x-axis  is 
defined  as  running  from  this  point  out  to  where  the  equator  and  the  Prime 
Meridian  intersect.  The  positive  y-axis  runs  from  the  center  point  out  to  where  the 
equator  intersects  the  90  degree  east  meridian,  and  the  positive  z-axis  points 
from  the  center  toward  the  North  Pole.  The  “dis.js”  library  provides  methods  to 
convert  coordinates  between  ECEF  and  ENU  (east,  north  and  up),  which  is  a  set 
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of  local  coordinates  with  a  given  geodetic  point.  Figure  16  presents  the 
coordinate  systems  of  ECEF  and  ENU.  The  “dis.js”  also  helps  convert  between 
ECEF  and  latitude,  longitude  and  altitude. 

The  tank  game  is  a  self-interactive  game,  which  means  players  are  always 
in  the  same  local  coordinate  system.  The  game,  however,  still  converts  its  local 
coordinates  from  ENU  to  ECEF  in  case  other  DIS  simulations  want  to 
communicate  with  it  in  the  future.  Besides  the  conversion  of  location,  the  entity’s 
orientation  must  also  be  converted.  Rotation  in  three.js  is  based  on  quaternion, 
which  uses  four  numbers  to  represent  an  entity’s  orientation  in  a  3D  world.  On 
the  other  hand,  ESPDU  only  provides  three  fields  that  are  Euler  angles  to 
express  orientation.  There  are  many  examples  of  conversion  between  quaternion 
and  Euler  angles  on  the  Internet.  Figure  17  is  an  example  of  a  conversion 
between  coordinates. 

ZlH* 


Figure  16.  Earth  centered,  earth  fixed;  and  east,  north,  up  coordinates 

(“Axes  conventions,”  n.d.) 
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var  rangeCoordinates  =  new  dis.RangeCoordinates(0.0, 0.0, 0.0); 

//  convert  from  local  coordinate  system  to  global  coordinate  system, 
var  localToGlobal  -  function  (entity) 

{ 

var  entityPosition-  {x:entity.tank.mesh.position.x, 

y.-entity.tank.mesh.position.y,  z:entity.tank.mesh.position.2}; 
vartoGlobalCoordi  nates  =  rangeCoordinates.ENUObjectToECEF(entityPosition); 
entity.lastEspdu.entityLocation.x  =  toGlobalCoordinates.x; 
entity.lastEspdu.entityLocation.y=  toGlobalCoordinates.y; 
entity.lastEspdu.entityLocation.z  =  toGlobalCoordinates.z; 

//orientation 

var  pitchYawRoll=  quatToEuler(entity.tank.mesh. quaternion); 
entity.lastEspdu.entityOrientation.theta  -  pitchYawRoll.y; 

}; 

//convert  from  global  coordinatesto  local  coordinate  system, 
var  globalToLocal  =  function(mesh,  espud) 

{ 

var  localCoordinates=  rangeCoordinates.ECEFObjectToEIMU(espud.entityLccation); 
mesh.position.x  =  localCoordinates.x; 
mesh.position.y=  localCoordinates.y; 
mesh,  position,  z  =  localCoordinates.z; 

//orientation 

mesh,  rotation. y=  espud.entityOrientation.theta; 


Figure  17.  Conversion  between  ECEF  and  ENU. 


6.  Send  DIS  Packets 

DIS  simulation  uses  heartbeat  strategy  that  periodically  sends  DIS 
packets  to  update  entity  information  and  maintain  entity  existence;  the  “dis.js” 
library  provides  methods  to  convert  every  DIS  PDU  from  JavaScript  object  into 
binary  format  DIS  messages.  In  the  demonstration  tank  game,  entity  state  PDUs 
were  sent  periodically  to  the  server  or  other  PeerJS  clients. 

Collision  PDU  and  fire  PDU,  on  the  other  hand,  are  event-oriented. 
Collision  PDUs  were  issued  when  there  was  a  collision  event  between  a  tank 
missile  and  opposing  tank.  Fire  PDUs  were  issued  whenever  someone  was 


35 


shooting.  The  periodic  sending  of  DIS  PDUs  also  helped  maintain  entity 
existence  in  other  clients,  because  each  client  browser  would  check  the  receiving 
time  for  every  entity.  If  an  entity’s  last  receiving  time  was  3  seconds  ago,  which 
was  a  game  setting,  this  entity  would  be  removed  from  client  browsers.  Figure  18 
shows  example  code  of  a  heartbeat  function  in  setlnterval  method,  and  a 
trimmed  DIS  message  that  was  transferred  via  the  WebSocket. 


var  heartbeat  =  function() 

{ 

var  dataBuffer=  new  ArrayBuffer(1500); 

var  outputStream  =  new  dis.OutputStream(dataBuffer); 

ourEntity.lastEspdu.encodeToBinaryDIS(outputStream); 

var  trimmedData  =  dataBuffer.slice(0,  outputStream. currentPosition); 

websocket.send(trimmedData); 

}; 


//  Periodically  send  heartbeat  messages 
setlnterval(heartbeat,  10); 

Figure  18.  Heartbeat  function. 

PeerJS  uses  a  similar  method  to  send  DIS  messages,  but  the  sending 
mechanism  is  via  PeerJS  DataConnection  object.  Figure  19  shows  how  to  create 
a  DataConnection  object  from  a  peer  object,  and  the  sending  method.  The 
trimmedData  is  the  same  with  WebSocket. 


var  connectTo=  peer.connect('other  peerlD'); 

connectTo.send(trimmedData); 

Figure  19.  PeerJS  sending  method. 
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7. 


Receive  and  Decode  DIS  Messages 


The  codes  used  to  receive  data  are  different  between  WebSocket  and 
PeerJS.  The  decoding  processes,  however,  are  the  same. 

a.  Receive  by  WebSocket 

Before  receiving  data  from  WebSocket,  the  format  to  receive  binary 
messages  and  attach  functions  for  various  events  must  be  set.  Figure  20  shows 
the  code  for  setting  the  WebSocket.  WebSocket.onmessage  is  the  function  used 
to  handle  receiving  data  from  the  server  site. 


websocket. binaryType  =  'arraybuffer'; 

websocket. onopen  =  function(evt){console.log("websocket  onopen");}; 
websocket.  onclose  =  function(evt){console.log("websocket  close");}; 
websocket. onerror=  function(evt){console.logf 'websocket  error");}; 
websocket.onmessage  =  function(evt){ 

// Handle  received  DIS  messages  here 

}; 


Figure  20.  Set  format  and  attach  functions. 

b.  Receive  by  PeerJS 

After  creating  a  peer  object,  developers  have  to  set  listeners  for  peer 
events.  The  main  method  this  thesis  used  was  “peer.on,”  and  the  listening  event 
was  “connection,”  with  a  function  to  handle  the  incoming  messages.  This  event 
will  receive  a  dataConnection  object,  which  wraps  WebRTC’s  DataChannel,  and 
pass  this  object  to  the  handling  function.  Figure  21  shows  the  code  to  listen  for 
events. 

peer.on(Fconnection',  function(dataConnection)  {„. }); 

Figure  21 .  PeerJS  event  listener. 
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The  DataConnection  class  contains  three  methods:  “send,”  “close”  and 
“on.”  The  “send”  method  sends  data  to  the  remote  peer,  and  “close”  closes  the 
data  connection  and  cleans  up  underlying  DataChannels  and  PeerConnections. 
The  “on”  method  can  be  set  for  listening  for  data  connection  events:  “data,” 
“open,”  “close”  and  “error.”  The  thesis  experiments  used  the  “data”  event  that  is 
emitted  when  data  is  received  from  remote  peers  to  receive  and  handle  DIS 
messages.  Figure  22  shows  the  example  code. 


peer.on('connection',  connect); 

function  connect(connReceived)  { 
var  peerld  =  connReceived.peer; 
console. log('remote  peer  id:  ’,peerld); 

connReceived.onCdata',  function(data){ 

//Handle  received  DIS  messages  here 

}); 

connReceived.onfclose^functionQi 
delete  connectedPeers[peerld]; 

}); 

} 

Figure  22.  Example  code  of  receiving  events  function. 

c.  Decoding  DIS  Messages 

The  mechanism  of  decoding  DIS  packets  is  the  same  in  WebSocket  and 
WebRTC  because  both  rely  on  the  “dis.js”  library  to  interpret  DIS  messages.  The 
function  of  the  WebSocket  and  the  WebRTC  is  to  send  and  receive  application 
data.  The  first  step  in  interpreting  DIS  messages  is  to  allocate  packets  to 
different  types  of  PDUs  using  a  method  called  dis.PduFactory().  Different  PDUs 
contain  different  information  with  different  data  lengths.  Every  PDU,  however, 
has  the  same  PDU  header,  which  has  96  bits  to  restore  basic  information  such 
as  protocol  version  (8-bit  enumeration),  exercise  ID  (8-bit  unsigned  integer),  and 
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PDU  type  (8-bit  enumeration).  The  dis.PduFactory()  method  uses  the  PDU  type, 
which  is  the  third  byte  in  the  PDU  header,  to  distinguish  what  kind  of  PDU  should 
be  assigned.  The  demonstration  game  in  this  thesis  used  three  different  types  of 
PDUs:  entity  state  PDU,  collision  PDU,  and  fire  PDU.  The  respective  lengths  of 
these  three  DIS  PDUs  are  1152  bits,  480  bits  and  768  bits,  and  the  respective 
enumeration  numbers  of  these  three  PDUs  are  1,  4,  and  2.  Figure  23  shows  how 
to  use  dis.PduFactory(). 

var  pduFactory  =  new  dis.PduFactory(); 

var  newPdu  =  pduFactory.createPdu(evt.data);//Websocket 

var  newPdu  =  pduFactory.createPdu(data);//PeerJS 

Figure  23.  Example  code  of  dis.PduFactory(). 

After  differentiating  the  PDU  type,  it  is  time  to  deal  with  receiving  the  DIS 
messages:  entity  state  PDU,  collision  PDU,  and  fire  PDU.  ESPDU  is  used  to 
update  entity  states  in  client  browsers.  Every  client  would  create  a  JavaScript 
object,  which  is  used  to  record  all  remote  entities  from  other  game  participants.  If 
the  receiving  ESPDU’s  entity  ID  did  not  previously  exist,  client  browsers  will 
recode  the  new  ESPDU  in  an  all-remote-entity  object,  and  create  a 
corresponding  3D  model  loaded  by  JSON  loader  to  represent  this  entity  ID.  If 
there  is  a  3D  model  having  the  same  entity  ID  corresponding  with  the  receiving 
ESPDU,  browsers  will  update  this  3D  model’s  states  such  as  location,  velocity, 
and  orientation.  Collision  PDUs  will  be  issued  when  a  collision  occurs  between 
entities.  In  the  demonstration  tank  game,  collision  PDUs  were  issued  whenever  a 
tank  got  hit;  both  the  firing  missile  and  the  hit  tank  issued  collision  PDUs.  Fire 
PDU  in  this  scenario  was  for  showing  all  firing  events  on  the  screen. 
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8. 


Miscellaneous 


There  are  some  miscellaneous  things  that  have  not  been  mentioned,  but 
which  are  also  very  important  for  creating  a  browser-based  DIS  simulation. 
These  include  how  to  load  meshes,  how  to  detect  collision  in  a  virtual 
environment,  how  to  ensure  entity  existence,  and  the  application  of  dead 
reckoning. 


a.  Loading  3D  Objects 

Creating  the  3D  graphics  took  longer  than  creating  a  JavaScript  object. 
When  a  client  browser  received  an  ESPDU  whose  entity  ID  was  new  to  this  client, 
the  client  would  create  a  3D  model  to  represent  this  new  entity.  The  3D  model, 
however,  could  not  be  located  immediately  in  the  virtual  world  before  it  was  fully 
loaded.  In  the  tank  game  example,  a  function  continued  updating  entity  states 
and  the  corresponding  3D  model  each  time  the  clients  received  the  same 
ESPDUs.  Once  the  3D  model  was  fully  loaded  into  the  virtual  world,  an  opposing 
tank  would  show  in  the  browser.  The  following  code  describes  a  way  to  update 
entity  and  3D  model  properties.  Figure  24  shows  the  code  of  updating  the  entity’s 
model  and  states. 
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var  updateEntityMesh  =  function  () 

{ 

for(var  e  =  0;  e  <  needUpdateEntityArray.length;  e++  ) 

{ 

var  needUpdateEntity  =  needUpdateEntityArray.shift(); 
for(var  eidString  in  allEntities) 

{ 

var  currentEntity  =  allEntitiesfeidString]; 
if(eid5tring  ===  needUpdateEntity) 

{ 

if(currentEntity.munition) 

{ 

if(currentEntity.munition.mesh) 

{ 

if(currentEntity.lastEspdu.entityType.entityKind  2) 

{ 

globafTbLocaf(currentEntity.munition,mesh,  currentEntityJastEspdu); 

Dead  Reckon  mgPa  ra  nneterGloba  iTaLoca  !(currentEntr^.^n  Lmiticn ,  cu  rrentEnt  rtyJ  astEspdu); 
allEntitiesfeidString]  =  currentEntity; 

} 

> 

t 

if(currentEntity.tank) 

{ 

if(currentEntity.tank.mesh) 

t 

globa)ToLocal(currentEntity.t3ric.mesh,  currentEntity.  lastEspdu); 
allEntities[eid5tring]  =  currentEntity; 

} 

} 

} 

} 

} 

}; 

Figure  24.  Code  of  updating  entity  states  and  3D  model. 


b.  Entity  Collision  Detection 

The  “three.js”  library  provides  methods  for  ray  casting  that  can  be  used  to 
detect  collision  in  a  virtual  world.  The  way  of  using  ray  casting  is  to  push  all 
prospective  collided  objects  into  an  array  before  doing  ray  casting.  In  the 
demonstration  game,  ray  casting  was  used  for  checking  collisions  between:  tank 
and  terrain,  tank  and  tank,  and  tank  and  skybox.  Tanks  cast  a  ray  to  minus  the  y- 
axis  (i.e.,  toward  the  ground),  so  that  they  could  rise  and  fall  on  (i.e.,  “follow”)  the 
terrain  by  having  a  collision  between  tank  and  terrain.  Tanks  also  cast  rays  in 
another  four  directions — front,  rear,  right,  and  left — for  detecting  other  tanks  and 
any  vertical  terrain.  Ray  casting  in  this  game  was  used  not  only  for  collision 
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detection,  but  also  for  pointing  out  missile  directions:  shooting  a  ray  from  a  turret 
to  find  a  collision  point,  and  then  using  this  point  to  determine  projectile  path  by 
computing  between  colliding  point  and  turret. 

c.  Checking  Existence 

The  DIS  is  a  heartbeat-based  simulation,  so  every  client  should  receive 
ESPDUs  periodically  from  other  clients.  There  is  a  field  in  the  PDU  header  for 
timestamp.  This  field  can  be  used  to  record  the  last  time  heard  from  other 
ESPDUs.  If  a  simulation  participant  did  not  receive  ESPDUs  from  remote  peers 
in  a  period-of-time,  the  participant  removed  3D  models  and  properties  that 
belonged  to  those  remote  peers.  There  were  six  elements  removed  when  the 
client  browser  did  not  hear  any  ESPDU  from  a  specific  peer:  tank  mesh  and 
ammunition  mesh  in  the  scene,  tank,  and  ammunition  properties  in  the  all- 
remote-entity  object,  and  tank  and  ammunition  objects  in  the  collision  array. 

d.  Dead  Reckoning 

Dead  reckoning  is  used  to  predict  an  entity’s  next  position  by  using  the 
entity’s  current  position  with  a  dead-reckoning  algorithm,  linear  acceleration, 
angular  velocity,  and  other  parameters  when  the  entity  does  not  receive  the  next 
prospective  ESPDUs  to  update  its  position.  Dead  reckoning  can  be  utilized  to 
cover  an  entity’s  stutters  caused  by  the  heartbeat  period.  The  demonstration  tank 
game  used  dead  reckoning  for  a  projectile’s  movement  to  reduce  visual  jumping, 
in-browser,  of  other  game  participants.  A  projectile’s  movement  with  dead 
reckoning  that  complements  intervals  between  two  consecutive  ESPDUs  also 
increases  the  accuracy  of  issuing  collision  PDUs,  because  the  heartbeat  strategy 
might  cause  the  projectile  to  “jump”  over  an  opponent’s  tank  without  any  collision 
or  intersection. 
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V.  PERFORMANCE  TESTS 


This  thesis  investigated  two  networking  frameworks,  WebSocket  and 
WebRTC,  and  used  these  two  frameworks  in  performance  experiments  and  the 
resulting  data.  The  WebSocket  was  constructed  as  client-server  architecture.  In 
contrast,  the  WebRTC  was  based  on  peer-to-peer  architecture  after  a  data 
channel  was  constructed.  This  thesis  also  incorporated  WebGL  components  as  a 
comparable  factor,  which  compared  the  presences  of  WebGL  components  in  the 
browser.  WebGL  enabled  the  browser’s  rendering  of  2D  and  3D  graphics,  but  it 
also  increased  CPU  and  GPU  loadings  by  computing  graphics  transformation, 
scaling,  rotation,  translation,  etc.  Furthermore,  different  browsers  used  different 
JavaScript  engines,  so  the  differences  between  the  browsers  (Chrome  version 
36.0.1985.143m  and  Firefox  version  24.7.0)  were  compared.  Measuring  tools  for 
this  thesis  included  self-created  functions,  Chrome  developer  tools,  and  Firefox 
developer  tools. 

A.  SENDING  AND  RECEIVING  ABILITY 

To  measure  the  sending  performances  in  different  networking  framework 
and  browsers,  this  thesis  created  a  function  to  send  ESPDU  packets.  The 
receiving  numbers  were  increased  when  the  onmessage  function  was  called  and 
packets  were  received  by  the  WebSocket.  The  PeerJS  received  PDUs  when  the 
dataConnection  object  heard  ‘data’  events.  Figure  25  shows  the  measureDIS 
function  for  sending  DIS  packets  in  WebSocket.  The  measurement  evaluated 
how  much  time  was  needed  for  sending  10,000  DIS  packets,  with  millisecond  as 
the  time  unit.  The  function  had  a  ‘sendercounter’  variable  to  cumulate  the  total 
number  of  sending.  At  the  same  time,  this  function  also  converted  the  total 
number  to  a  serial  number  for  dropping  test  into  the  entityAppearance  field  in 
ESPDU.  PeerJS  used  connectTo  (a  dataConnection  object)  to  send  the  trimmed 
data  (see  Chapter  IV,  Section  6,  Send  DIS  Packets). 
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var  measureDlS  -  function() 

{ 

ourEntityJastEspdu  -  new  dis.EntityStatePdu(); 
startTime  =  new  Date(); 
senderCounter  =  0; 
whilejsenderCounter  <  100Q0) 

( 

ourEntity.  [a  stEspd  u  .entityAp  pea  ranee  -  totafSend +1; 

var  dataBuffer  -  new  ArrayBuffer(150Q); 

var  outputstream  =  new  d  is. autputstream(data  Buffer}; 

ourEntityJastEspdu  .encodeloBina  ryD  IS(  outputstream}; 

var  trimmed  Data  =  dat3Buffer.slice(G,  outputstream  xurrentPosition); 

wet)  socket .  se  n  d  (t  ri  m  m  ed  Data ); 

senderCounter  ++; 

totafSend  ++; 

} 

endTime  =  new  Dated; 

var  eiapsedTime  =  endTime. getTTmeQ  -  start Time.getTime(); 
console  Jogf  "time:",  elapsedTime,  "  send  packets:11,  senderCounter); 


Figure  25.  MeasureDlS  function  for  sending  DIS  packets. 


Figure  26  shows  the  example  of  a  WebSocket  receiving  DIS  packets.  The 
measurement  was  the  same  with  the  sending  function  that  measured  how  much 
time  was  needed  for  receiving  10,000  PDUs.  Figure  27  shows  the  method  that 
the  PeerJS  used  to  receive  data. 


websocket.onmessage  =  function(evt) 

{ 

receiveCounter++; 
total  Receive  ++, 

if(receivcCountcr===  l){startTimc  =  new  Date();} 
if(receiveCounter%  10000  ===  0) 

{ 

var  endTime  =  new  Date(); 

var  elapsedTime=  endTime. getTimeQ-  startTime.getTimeO; 

cnn<;olp.logj,1time:",  plapserlTime,  “rerpive  parket<;!H,  rereivpCotinVer); 
receiveCounter=  0; 
startTime  =  new  Dale(); 

} 

}; 


Figure  26.  Measuring  function  of  receiving  DIS  packets  in  WebSocket. 
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connReceived.on('data',  function(data) 

{ 

//same  with  websocket  onmessage. 

receiveCounter++; 

total  Receive  ++; 

if(receiveCounter  ===  l){startTime  =  new  Date();} 

}); 

Figure  27.  Measuring  function  of  receiving  DIS  packets  in  PeerJS. 

The  following  section  shows  the  transformed  outcomes  of  running  the 
above  functions  20  times  based  on  a  one-on-one  situation,  one  sender,  and  one 
receiver.  As  a  result,  20  runs  of  a  specific  time  were  spent  on  sending  and 
receiving  10,000  PDUs.  The  thesis  used  MS  Excel  to  convert  the  results  into  the 
number  of  Entity  State  PDUs  that  were  sending  and  receiving  per  second,  and 
used  JMP  for  statistics. 

Figure  28  shows  the  outcome  of  pure  sending  and  receiving  rates  in 
different  combinations  of  browsers.  The  left  eight  experiments  are  receivers,  and 
the  remaining  experiments  are  senders.  The  green  lines  are  the  means  of  each 
experiment,  and  the  blue  bars  can  be  used  to  visually  compare  the  statistical 
difference  between  any  pair  of  experiments.  If  a  pair  of  bars  overlaps  from  each 
other,  these  two  experiments  are  not  significantly  different,  and  vice  versa.  CC 
means  that  the  Chrome  browser  sent  to  the  Chrome  browser;  CF  means  the 
Chrome  browser  sent  to  the  Firefox  browser,  and  so  on.  Figure  28  shows  that 
senders  were  overwhelmingly  faster  than  recipients,  because  the  sending  rates 
were  counted  by  executing  the  measureDIS  function  instead  of  actually  sending 
out  to  the  browsers.  In  addition,  none  of  the  experiments  found  message  losses 
in  the  WebSocket  framework,  and  rarely  were  the  DIS  packets  lossed  in  the 
WebRTC  framework.  The  sending  data  was  not  sent  out  by  browsers;  instead,  it 
was  queued  in  the  senders’  memory.  For  example,  if  a  sender’s  browser  invoked 
a  function  that  used  WebSocket  to  send  10,000  ESPDUs  per  second,  but  the 
receiver  only  got  7,000  PDUs  per  second;  the  remaining  3000  ESPDUs  per 
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second  would  buffer  in  the  sender’s  memory.  Hence,  the  performances  of 
sending  and  receiving  DIS  messages  in  different  frameworks  in  different 
browsers  should  refer  to  the  receiving  throughputs. 

Figure  29  focuses  on  the  DIS  receiving  rates,  and  shows  that  the 
WebSocket  had  relatively  stable  receiving  rates  (around  7,000  to  8,000  per 
second  in  different  browsers).  According  to  the  WebSocket  framework — which 
was  client-server  architecture — the  recipients  received  DIS  packets  from  the 
WebSocket  gateway  server,  which  means  the  receiving  performances  are 
dependent  on  the  server’s  capability.  In  contrast,  the  receiving  abilities  of  PeerJS, 
which  implemented  WebRTC  and  were  based  on  peer-to-peer  connections,  were 
varied.  The  recipients  received  around  2,000  per  second  in  Chrome  sent  to 
Chrome  and  Chrome  sent  to  Firefox,  but  had  better  performance  of  around 
11,000  to  13,000  per  second  in  Firefox  sent  to  Chrome  and  Firefox  sent  to 
Firefox. 


Figure  28.  Purely  sending  and  receiving  capabilities. 
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According  to  the  above  conclusions,  sending  rates  did  not  correspond  to 
the  receiving  rates,  so  the  performance  with  WebGL  elements  should  focus  on 
the  receiving  capabilities.  Figure  30  shows  comparisons  between  the  presences 
of  WebGL,  and  reveals  that  these  were  graphically  different  among  the  mean 
lines.  It  seems  like  that  WebGL  had  some  level  of  influence  on  receiving  the  DIS 
messages,  because  the  receiving  capabilities  with  WebGL  elements  are  lower 
than  without  WebGL  elements. 
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Figure  30.  Comparisons  of  receiving  capabilities  between  the  presences  of 

WebGL. 

To  understand  the  differences  among  receiving  rates,  this  thesis  used  a 
student’s  t-tests  to  find  out  if  pairs  of  receiving  rates  were  significantly  different 
from  one  another.  By  looking  up  rates  in  the  table  of  t-distribution,  the  p-value 
could  be  found  to  compare  with  the  alpha  level.  This  thesis  used  0.01  as  the 
alpha.  If  the  p-value  greater  than  the  alpha,  there  was  no  significant  difference 
between  the  comparing  pair,  and  vice  versa.  The  p-value  only  indicated  the 
degree  of  difference;  it  did  not  indicate  any  better  performance.  Table  2  shows 
the  performances  of  that  the  WebSocket  framework  versus  the  WebRTC 
framework  was  significantly  different,  because  all  the  p-values  are  less  than 
0.0001.  The  differences  can  be  checked  graphically  in  Figure  29. 
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Comparison  between 

P- 

value 

experimental 

combination 

average  number  of 
receiving  PDUs 

experimental 

combination 

average  number  of 
receiving  PDUs 

CC+WebSocket 

7203.79 

CC+WebRTC 

2272.54 

<.0001 

CF+WebSocket 

8212.41 

CF+WebRTC 

2300.51 

<.0001 

FC+WebRTC 

12917.75 

FC+WebSocket 

7311.62 

<.0001 

FF+WebRTC 

11239.30 

FF+WebSocket 

7695.37 

<.0001 

Table  2.  t-tests  of  receiving  capability  in  WebSocket  and  WebRTC 

frameworks  without  WebGL  components.  The  experiment  at  left 
had  the  higher  performance. 


Table  3  presents  paring  comparisons  between  browsers  using  the 
WebSocket  framework;  all  the  p-values  are  greater  than  0.01,  which  means  there 
were  no  significant  difference  of  receiving  rates  between  browsers  when  using 
WebSocket  framework.  Greater  p-value  represents  less  difference  between  the 
comparing  pair.  The  WebSocket  framework  had  stable  performances  in  both 
Chrome  and  Firefox  browsers. 


Comparison  between 

experimental 

average  number  of 

experimental 

average  number  of 

P- 

value 

combination 

receiving  PDUs 

combination 

receiving  PDUs 

CF+WebSocket 

8212.41 

CC+WebSocket 

7203.79 

0.2151 

CF+WebSocket 

8212.41 

FC+WebSocket 

7311.62 

0.2681 

CF+WebSocket 

8212.41 

FF+WebSocket 

7695.37 

0.5247 

FF+WebSocket 

7695.37 

CC+WebSocket 

7203.79 

0.5453 

FF+WebSocket 

7695.37 

FC+WebSocket 

7311.62 

0.6368 

FC+WebSocket 

7311.62 

CC+WebSocket 

7203.79 

0.8944 

Table  3.  t-tests  of  receiving  capability  between  browsers  without  WebGL 

components  in  WebSocket  framework. 


On  the  other  hand,  Table  4  shows  paring  comparisons  between  browsers 
using  WebRTC  framework.  In  all  cases,  Firefox  is  shown  to  send  via  WebRTC 
significantly  faster  than  Chrome  does.  The  p-value  0.9725  indicates  that  using 
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the  Chrome  browser  to  send  DIS  packets  to  the  Chrome  browser  had  similar 
performance  when  using  the  Chrome  browser  to  send  DIS  packets  to  the  Firefox 
browser.  The  p-value  0.0395  indicates  that  using  the  Firefox  browser  to  DIS 
packets  to  the  Chrome  browser  had  similar  performance  as  using  the  Firefox 
browser  to  send  DIS  packets  to  the  Chrome  browser,  because  the  alpha  level 
was  0.01.  These  results  show  that  the  same  sender  had  similar  receiving  rates  in 
recipient  browsers. 


Comparison  between 

P-value 

experimental 

combination 

average  number  of 
receiving  PDUs 

experimental 

combination 

average  number  of 
receiving  PDUs 

FC+WebRTC 

12917.75 

CC+WebRTC 

2272.54 

<.0001 

FC+WebRTC 

12917.75 

CF+WebRTC 

2300.51 

<.0001 

FF+WebRTC 

11239.30 

CC+WebRTC 

2272.54 

<.0001 

FF+WebRTC 

11239.30 

CF+WebRTC 

2300.51 

<.0001 

FC+WebRTC 

12917.75 

FF+WebRTC 

11239.30 

0.0395 

CF+WebRTC 

2300.51 

CC+WebRTC 

2272.54 

0.9725 

Table  4.  t-tests  of  receiving  capability  between  browsers  without  WebGL 

components  in  WebRTC  framework. 


The  last  pairing  comparisons  were  the  differences  between  the  presence 
of  WebGL  materials  (see  Table  5).  It  is  hard  to  decide  whether  the  presences  of 
WebGL  materials  affected  the  PDU  sending  and  receiving  performance,  because 
there  were  two  p-values  that  were  less  than  0.01.  Most  comparisons,  however, 
were  not  significantly  different  from  each  other.  Besides  focusing  on  Table  5,  the 
comparisons  with  less  than  0.01  p-values  had  very  good  performances  on 
sending  and  receiving  DIS  messages.  Figure  30  shows  that  both 
FF+WebRTC+WebGL  and  CF+WebSocket+WebGL  had  the  capability  of 
sending  and  receiving  more  than  5,000  DIS  packets  per  second,  which  was 
much  faster  than  using  the  Chrome  sent  to  Chrome  and  the  Chrome  sent  to 
Firefox  in  the  WebRTC  framework. 
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Comparison  between 

P- 

value 

experimental 

combination 

average 
number  of 
receiving 
PDUs 

experimental 

combination 

average 
number  of 
receiving 
PDUs 

FF+WebRTC 

11239.30 

FF+WebRTC+WebGL 

8562.47 

0.0011 

CF+WebSocket 

8212.41 

CF+WebSocket+WebGL 

6008.55 

0.007 

CC+WebSocket 

7203.79 

CC+WebSocket+WebGL 

5568.12 

0.0448 

FF+WebSocket 

7695.37 

FF+WebSocket+WebGL 

6096.03 

0.0497 

FC+WebSocket 

7311.62 

FC+WebSocket+WebGL 

5727.37 

0.0519 

FC+WebRTC 

12917.75 

FC+WebRTC+WebGL 

11403.85 

0.0632 

CC+WebRTC 

2272.54 

CC+WebRTC+WebGL 

1877.29 

0.6267 

CF+WebRTC 

2300.51 

CF+WebRTC+WebGL 

1931.61 

0.6499 

Table  5.  t-test  between  presences  of  WebGL  components 


B.  PROFILING  JAVASCRIPT  PERFORMANCES 

This  thesis  used  Chrome  developer  tools  and  Firefox  developer  tools  to 
profile  experimental  browsers.  The  profiling  tools  were  used  to  record  JavaScript 
performances  in  a  period-of-time,  and  the  recording  data  included  percentages  of 
time  spent  and  explicit  time  spent  for  each  function  in  this  period-of-time.  For 
example,  if  a  user  starts  profiling  then  running  the  measureDIS  function  for  two 
different  lengths  of  time — one  long  and  the  other  short — the  measureDIS  function 
would  occupy  a  small  percentage  of  the  long  period,  but  more  in  the  short  period. 
Figure  31  shows  running  the  measureDIS  function  in  a  long  period-of-time,  and 
Figure  32  shows  running  the  same  function  in  a  short  period-of-time.  The 
difference  was  through  running  the  measureDIS  function  with  a  shorter  time 
(39062.7  ms)  in  a  short  period;  this  function  still  captured  more  (19.06%)  than  the 
one  that  recorded  for  a  long  period-of-time  (40247.1  ms  with  10.15%).  The  ‘Self 
column  indicates  the  time  to  complete  the  current  function  that  excludes  any 
functions  it  called.  The  ‘Total’  column  shows  the  time  to  complete  the  current 
function  and  any  functions  it  called  (“Profiling  JavaScript  Performance,”  n.d.). 
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Eline  Profile  Resource  Audits  CghsoIe 

Net  Beans 

Tree  'Top  Down] 

v  O  X 

Setf  t 

Total 

Function 

350539.9  mi  »«57  V 

350339.9  ms  '3.57  \- 

(idle) 

4575.4  ms  !  [6 

4575.4  m5  !  L'i  : 

(program) 

4493  ms  'MI 

449.3  ms  M3 

Igai bag t  collector) 

23.6  ms 

402474  ms 

*  {anonymous  function) 

IQQB'1  ms  0.15  -  ■ 

40216.1  ms  . 

►  measureDIS 

2  A  ms  0  oo  L  ■  | 

2.4  ms  00  ■ 

ti  fli  s.Cntity^taf  ePdg.enc  odeToB  many  DES 

4.3ms 

4.3  ms  0o- 

set  name 

Figure  31 .  Running  measureDIS  function  for  a  long  period-of-time. 


eline  Profiles 
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NetBeans 
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* 
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Function _ 
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’  153119,2  mf 

74,72% 

(Idle) 

12311.2  ms 

bill-. 

12311.2  ms 

b.Ul% 

[program} 
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3.2  ms 
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0.00  'A 

d  i  s .  Ds  a  d  Reckcsnrn  g  Pa  ra  m  ete  r.  t  ncodeTo  Binary  DIS 

Figure  32.  Running  measureDIS  function  for  a  short  period-of-time. 


Firefox  developer  tools  also  have  profiling  tools.  Furthermore,  the  package 
includes  a  function  to  select  a  certain  section  to  analyze  JavaScript 
performances,  so  the  behaviors  of  sending  and  receiving  DIS  PDUs  can  be 
examined.  Looking  at  the  above  results  of  sending  and  receiving  DIS  packet 
capabilities,  however,  the  data  interchanging  rates  should  refer  to  the  receiving 
capabilities;  this  means  that,  although  the  browser  consumes  all  resources  to 
execute  the  measureDIS  function,  the  efficient  outputs  would  not  reflect  on  the 
receivers.  Therefore,  it  is  not  worthwhile  to  check  the  JavaScript  performance  of 
purely  sending  DIS  packets.  Appendix  B-1  is  a  profiling  example  of  sending  DIS 
PDUs  in  the  WebSocket  framework.  Appendix  B-2  selects  a  section  that  focused 
on  the  sending  function.  Appendix  B-3  is  the  corresponding  receiver  in  this 
example,  which  evenly  consumed  approximately  5-7%  of  the  browser  resource. 
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After  understanding  the  characteristic  of  profiling  tools,  it  is  difficult  to 
analyze  a  browser’s  behavior  by  profiling  it  with  the  measureDIS  function, 
because  the  time  to  invoke  the  measureDIS  function  and  the  time  to  complete 
sending  and  receiving  DIS  messages  varies  in  different  networking  environments 
and  different  combinations  of  browsers.  Therefore,  this  thesis  used  the  profiling 
tools  to  record  the  JavaScript  performances  in  the  demonstration  tank  game  as  a 
practical  application,  instead  of  executing  the  measureDIS  function.  Based  on  the 
above  results,  applying  WebGL  materials  decreased  PDU  receiving  capability  in 
both  the  WebSocket  and  WebRTC  frameworks,  but  the  amount  of  receiving  DIS 
PDUs  remained  at  approximately  1,900  per  second. 

Figures  33  and  34  display  the  recording  of  the  tank  game  for  a  period-of- 
time  in  different  networking  frameworks.  The  game  setting  was  that  each  browser 
had  a  controllable  tank  and  a  projectile  that  could  be  fired  every  two  seconds. 
The  tank  and  projectile  sent  ESPDUs  every  ten  milliseconds,  which  was  different 
from  the  measureDIS  function  that  sent  200,000  ESPDUs,  successively.  The  fire 
PDU  and  collision  PDU  were  sent  when  the  corresponding  events  happened. 
The  advantage  of  profiling  the  tank  game  is  that  it  is  easy  to  analyze  the  sending 
and  receiving  performances  with  WebGL  elements  in  different  networking 
frameworks,  and  in  client-server  versus  peer-to-peer  configurations.  Because  the 
profiling  tools  used  the  percentage  of  function  executing  time  and  most  of  the 
functions  were  invoked  periodically  (which  included  graphical  rendering  and  DIS 
heartbeat  functions),  the  different  profiling  times  did  not  influence  the  results. 

This  tank  game  sent  approximately  200  ESPDUs  per  second,  which  is 
below  the  receiving  capabilities  in  any  situation.  Figure  33  is  a  profile  of  the  tank 
game  using  the  WebSocket  framework.  The  profile  showed  that  the  renderFunc 
function  consumed  32.99%  of  the  recording  time  to  execute  this  function.  The 
renderFunc  function  is  a  major  function  in  this  tank  game,  used  to  render 
graphics  and  check  collisions  between  3D  objects  in  the  virtual  world.  It 
contained  the  tank.update  function  and  many  ‘THREE’  functions,  which  indicated 
the  browser  spent  most  of  its  resources  on  the  WebGL  materials.  In  addition,  the 
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websocket.onmessage,  heartbeat  and  munitionHeartbeat  functions  could  be 
found  near  the  bottom  of  the  Function  column.  The  respective  percentages  for 
these  three  functions  are  0.78%,  0.41%,  and  0.33%  in  the  ‘Total’  column.  These 
results  showed  that  the  exchange  of  DIS  messages  did  not  give  browsers  a 
heavy  workload.  Figure  34  is  a  profile  of  the  tank  game  using  the  WebRTC 
framework,  and  it  shows  a  similar  performance  with  using  WebSocket  framework. 
The  function  of  _dc.onmessage  near  the  bottom  of  the  Function  column  is  similar 
to  the  function  of  websocket.onmessage  in  WebSocket  for  listening  to  incoming 
events.  Firefox  developer  tools  profiled  similar  results,  which  are  shown  in 
Appendix  C-1  and  C-2.  C-1 ,  used  the  WebSocket  framework,  and  C-2  used  the 
WebRTC  framework. 
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Figure  33. 


Tank  game  profile  using  WebSocket  framework  in  Chrome. 
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Figure  34. 

Tank  game  profile  using  WebRTC  framework  in  Chrome. 

C.  NETWORK  LOADING  TIME 

Besides  the  JavaScript  performances,  developer  tools  also  provide 
function  to  record  networking  behaviors.  The  recording  network  information 
included  file  name,  path,  status,  size,  loading  time,  etc.  When  a  browser  visited  a 
website  initially,  it  downloaded  cached  web  contents  from  the  web  server  to  the 
local  disk.  The  purpose  of  caching  web  contents  was  to  reduce  network  loading, 
because  if  the  browser  visited  the  same  website  in  a  specific  period-of-time,  the 
browser  would  verify  the  status  of  web  contents  to  decide  whether  to  download 
the  web  content  via  the  network  or  access  the  content  from  the  local  disk.  For 
example,  if  a  file  status  showed  200,  it  meant  the  file  was  new  to  this  browser 
and  it  was  downloaded  via  the  network.  If  a  file  status  showed  304,  it  meant  the 
file  had  not  been  modified  since  the  last  time  it  was  cached,  so  the  browser 
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would  access  the  file  from  the  local  disk.  These  numbers  are  HTTP  status  codes 
that  can  be  looked  up  on  the  Internet.  In  this  thesis,  the  web  server’s  default  time 
of  caching  web  content  was  604,800  seconds,  or  one  week.  All  the  performance 
tests  and  tank  games  were  run  in  a  closed  networking  environment,  so  the  speed 
of  loading  web  contents  was  very  fast.  The  total  loads  of  the  tank  game  were 
around  6  MB  for  a  single  player  (see  Appendix  D).  Most  of  the  data  consisted  of 
graphical  models  and  textures.  This  thesis  used  a  simple  tank  model  and  rough 
terrain  model  to  create  a  virtual  world  in  browsers.  Figure  35  and  Figure  36  are 
screenshots  of  the  tank  model  and  the  terrain  models.  The  file  sizes  of  these  two 
models  (hovertanklO.js  and  bterrain.js)  were  not  large;  however,  the  textures  for 
these  two  models  were  relatively  larger  than  other  necessary  archives.  The 
tank’s  texture  was  1.1  MB,  and  the  terrain’s  texture  was  2.5  MB.  Other 
JavaScript  files  (including  three.js,  peer.js,  dis.js,  etc.)  only  made  up  a  small 
percentage  of  the  total  web  contents. 


Figure  35.  Screenshot  of  tank  model. 
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Figure  36.  Screenshot  of  terrain  model. 
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VI.  RESULT  DISCUSSIONS 


According  to  the  sending  and  receiving  ability  tests,  this  thesis  found  that 
different  combinations  of  browsers  and  different  networking  frameworks  had 
various  capabilities  of  sending  and  receiving  DIS  PDUs.  The  outcomes  showed 
that  estimates  of  the  PDU  exchange  rate  should  be  based  on  the  rate  of  PDU 
receipt.  By  analyzing  the  senders’  memory  change,  it  was  discovered  that 
sending  pages  buffered  their  sending  data  in  their  memory,  instead  of  sending 
the  data  immediately.  Although  senders  queued  the  sending  data  in  their 
memories,  Chrome  and  Firefox  handled  their  sending  events  differently,  which 
made  for  different  efficiencies.  Secondly,  analyzing  the  profiling  results  showed 
that  browsers  spent  their  resources  mostly  on  WebGL  components  that  included 
rendering  3D  models  and  computing  intersections  between  3D  objects.  The 
interchange  of  DIS  messages  did  not  account  for  a  big  usage  of  browser 
resources.  Thirdly,  the  web  contents  that  necessarily  were  downloaded  from  the 
web  server  to  local  browsers  did  not  give  any  trouble  in  a  local  network  in  the 
experiments.  Downloading  web  contents  by  remote  users  might  cause  latent 
problems  such  as  slowing  download  or  losing  data  if  the  necessary  files  were  on 
the  Internet  or  public  network  with  poor  connection,  which  might  also  affect  the 
capability  of  exchanging  DIS  messages.  Finally,  according  to  the  performance 
tests,  the  scale  of  web-based  simulation  using  DIS  protocol  can  be  proposed. 

A.  SENDING  AND  RECEIVING  EFFICIENCY 

According  to  the  performance  tests,  WebSocket  framework  had  consistent 
receiving  rates  in  both  Chrome  and  Firefox,  because  the  receiving  rates  were 
based  on  the  outputting  rate  from  the  WebSocket  gateway  server.  After  taking  a 
deeper  look  at  WebSocket  gateway  server,  the  server’s  receiving  rate  of  DIS 
messages  was  close  to  the  receiving  rates  in  recipient  browsers,  which  indicated 
the  WebSocket  gateway  server  was  efficient  in  transferring  DIS  packets. 
Additionally,  this  server  neither  use  multicast  nor  broadcast,  which  were  the 
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customary  ways  to  distribute  DIS  packets  on  the  UDP  socket.  Instead,  the  server 
delivered  DIS  PDUs  to  clients  one  by  one  because  WebSocket  is  constructed  on 
top  of  the  TCP  socket.  For  example,  if  there  are  only  two  clients  connecting  to 
the  server,  client  A  and  client  B,  when  client  A  is  sending  DIS  messages,  the 
server  only  distributes  the  receiving  data  to  client  B.  If  there  are  three  or  more 
clients,  the  server  has  to  distribute  the  receiving  data  to  all  connected  clients 
one-by-one,  except  for  the  sender  itself.  Therefore,  the  server  distributing  data  to 
multiple  clients  decreased  the  receiving  efficiency  on  recipient  clients. 

PeerJS  had  different  performances  in  different  browsers.  Implementing 
the  WebRTC,  PeerJS  used  peer-to-peer  architecture  to  transfer  data,  so  that  the 
sending  rate  would  correspond  to  the  receiving  rate.  The  above  results,  however, 
indicated  that  actually  the  sending  rates  should  refer  to  the  receiving  rates.  The 
results  also  showed  recipients  had  better  receiving  capabilities  when  using 
Firefox  to  send  data.  The  method  of  distributing  data  in  PeerJS  was  one-by- 
one — which  was  the  same  with  the  WebSocket  gateway  server — but  the 
WebSocket  framework  used  a  central  server  to  distribute  data.  The  WebRTC 
framework  is  set  up  so  that  every  participant  can  distribute  data  to  their 
connected  peers,  and  if  there  are  multiple  connections  to  a  peer,  the  receiving 
rates  on  connected  peers  will  decrease  in  an  inverse  ratio  (i.e.,  peer  A  can  send 
2,000  PDUs  per  second  to  peer  B  in  a  one-on-one  situation).  If  peer  A  has  to 
send  to  two  connected  peers,  peer  B  and  peer  C,  the  receiving  rate  in  both  peer 
B  and  peer  C  will  be  1 ,000  PDUs  per  second. 

By  analyzing  the  receiving  rates  between  browsers,  this  thesis  found 
Firefox  had  better  performances  for  sending  data  authentically  in  both 
frameworks.  Figure  37  presents  comparisons  of  receiving  rates  between  different 
networks  with  different  combinations  of  browsers.  The  x-axis  represents  the  time 
for  receiving  10,000  DIS  PDUs,  and  the  y-axis  represents  the  first  ten  10,000  DIS 
packets.  WebSocket  and  WebRTC  were  the  networking  architectures  for  data 
transferring.  When  senders  started  to  send  10,000  DIS  PDUs  for  twenty  times, 
receivers  should  have  begun  to  receive  data  immediately.  The  figure  shows, 

60 


however,  that  when  data  was  sent  from  the  Chrome  browsers,  the  recipients  took 
longer  to  receive  the  first  10,000  PDUs.  Another  expression  of  these  data  in 
linear  form  is  in  Appendix  E. 


Comparisons  of  receiving  first  ten  10,000  DIS  PDUs 
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Figure  37.  Comparisons  of  receiving  first  ten  10,000  DIS  PDUs. 


This  thesis  attempted  to  send  a  huge  amount  of  ESPDUs  (50,000 
ESPDUs  for  50  times),  which  crashed  the  Chrome  sender  after  flushing  and 
filling  all  the  memory,  and  the  receiver  stopped  receiving  DIS  packets.  Firefox 
reacted  in  a  different  way.  Although  the  Firefox  browser  indicated  that  it  was  not 
responding  to  the  sender,  the  receiver  continued  to  receive  DIS  PDUs 
persistently  from  a  slow  rate  to  a  fast  rate,  allowing  Firefox  to  successfully 
receive  all  2,500,000  DIS  packets  after  a  long  period-of-time.  Furthermore,  the 
transferring  data  was  not  lost  in  the  WebSocket  framework,  and  was  only  rarely 
lost  in  the  WebRTC  framework,  which  might  be  because  the  WebSocket  is  based 
on  the  TCP  socket,  while  the  WebRTC  used  the  SCTP  socket  to  configure  data. 
If  there  was  trouble  with  sending  data  in  the  WebSocket  framework,  then  the 
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WebSocket  would  close,  which  meant  that  the  webpage  had  to  be  reloaded  or  a 
WebSocket  reconstructed  in  the  browser.  If  the  trouble  happened  in  PeerJS,  it 
would  complain  that  the  DataConnection  object  could  not  send  data,  but  the  data 
channel  was  still  on;  the  browser  could  continue  to  send  data  after  dropping  all 
the  unsent  messages. 

B.  JAVASCRIPT  PERFORMANCE 

Profiling  of  the  tank  game  showed  that  most  of  the  browser  resources 
were  consumed  on  WebGL  components.  The  sending  and  receiving  functions 
only  occupied  small  portions  of  the  total  percentage  of  browser  resources.  To 
see  the  detailed  performances  of  each  JavaScript  function,  Chrome  and  Firefox 
developer  tools  provide  functions  to  see  the  explicit  times  of  each  function  used. 
This  capability  could  help  application  developers  and  designers  know  how  much 
time  is  spent  on  each  function. 

1.  Chrome  Developer  Tools 

The  profiling  sample  of  Figure  33  showed  the  Chrome  browser  consumed 
32.99%  of  the  total  time  to  run  the  renderFunc  function,  which  spent  6455.8  ms 
during  the  entire  period-of-time.  This  function,  however,  only  spent  28.4  ms  on 
itself.  The  rest  of  the  time  was  spent  on  other  functions  that  were  invoked  by  this 
function.  Chrome  Developer  Tools  also  provides  Flame  Chart  view,  which  is  a 
visual  representation  of  JavaScript  performance  over  time  that  thus  offers  a 
different  way  to  view  the  profiling  data.  It  also  provides  the  running  time  of  each 
function  with  single  invoking,  which  is  different  from  the  aggregated  time  of 
running  a  specific  function  repeatedly.  Figure  38  is  a  sample  of  invoking  one 
renderFunc  function  in  Flame  Chart  view.  The  information  of  the  Flame  Chart 
view  included  the  name  of  this  function,  self  time,  total  time,  URL,  aggregated 
self  time,  and  aggregated  total  time.  The  aggregated  total  time  of  the  renderFunc 
function  was  6.46  s  that  corresponded  to  the  time  6455.8  ms  in  Figure  33.  Figure 
39  was  a  portion  of  the  recording  profile  that  included  the  websocket.onmessage 
and  the  heartbeat  functions.  Looking  at  the  details  of  this  flame  chart,  found  that 
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the  running  times  of  both  functions,  respectively,  were  less  than  1  ms  per 
invoking,  and  the  aggregated  total  time  of  the  heartbeat  function  was  81.103  ms, 
which  was  much  shorter  than  6.46  s. 
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Figure  38.  A  Chrome  profiling  sample  of  invoking  one  renderFunc  function. 
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Figure  39.  A  Chrome  profiling  sample  of  invoking  one  websocket.onmessage 

and  one  heartbeat  function. 

2.  Firefox  Developer  Tools 

Firefox  developer  tools  also  have  the  ability  to  to  look  up  the  explicit  time 
of  each  function  consumed.  Figure  40  is  a  small  sample  of  profiling  the  tank 
game  with  two  players  in  the  WebRTC  environment.  This  sample  range  was  from 
2,353  to  2,403  of  the  complete  profile,  and  the  total  running  time  is  49ms.  If  the 
running  time  is  greater  than  the  self,  then  there  is  an  arrow  at  the  left  of  the 
function’s  name  to  expand  the  function  tree.  In  this  example,  the  renderFunc() 
function  spent  20  ms  in  running  time,  but  the  self  time  was  zero,  which  means 
this  function  was  expandable.  This  example  also  showed  that  five  renderFunc() 
functions  were  executed  in  this  49  ms,  which  corresponded  to  the  10ms 
rendering  rate.  The  executing  time  of  each  renderFunc()  can  be  found  by 
selecting  one  of  these  five  functions  and  expending  this  selected  function  to  see 
the  details  of  self  time. 
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Figure  40. 


A  Firefox  profiling  sample  of  invoking  renderFunc  functions. 


After  analyzing  the  JavaScript  performances  of  the  tank  game,  both 
profiling  tools  showed  that  even  though  the  heartbeat  and  the  munitionhleartbeat 
functions  were  invoked  at  the  same  rate  with  the  rendering  function,  the  browser 
devoted  a  large  part  of  its  resources  to  executing  WebGL  components  rather 
than  exchanging  DIS  PDUs.  Therefore,  the  native  capabilities  of  both  WebSocket 
and  WebRTC  in  browsers  are  competent  enough  to  support  web-based  DIS 
simulations. 

C.  LOAD  OF  NECESSARY  ARCHIVES 

Loading  page  content  from  the  server  was  no  problem  in  this 
demonstration  tank  game  because  of  the  following  reasons.  First,  all  the  tests 
were  executed  in  a  local  networking  environment.  Second,  the  distributed  files 
were  only  around  6M  B  for  each  client,  and  there  were  not  many  clients.  Third, 
the  client  computers  had  very  powerful  CPUs  and  graphic  cards.  If  someone 
wants  to  improve  the  sophistication  of  the  tank  game,  however,  then  the  archival 
size  of  models  and  textures  must  be  increased.  The  sophistication  of  the  model 
also  increases  the  burden  of  computational  power  in  clients.  There  are  many 
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existing  3D  models  in  various  formats  on  the  Internet,  and  it  is  easy  to  find  a 
sophisticated  model  over  10  MB.  Although  web  browser  has  capability  to  cache 
files  from  web  server,  it  still  has  to  load  every  necessary  archive  at  the  first  time. 
If  there  are  several  large-size  3D  models  that  have  to  be  downloaded  as  web 
contents,  the  data  distribution  via  public  network  would  become  a  fundamental 
issue  for  building  up  web-based  simulations.  There  are  some  popular  techniques 
for  reducing  the  impact  of  loading  large  data  into  web  page  such  as  minify 
JavaScript,  apply  Content  Delivery  Network,  remove  duplicate  scripts  (Souders, 
2007). 

D.  GAME  SCALABILITY 

According  to  the  results  from  performance  tests,  receiving  rates  were  the 
major  references  for  interchanging  DIS  PDUs  in  the  network.  Hence,  the 
receiving  rate  can  be  used  to  scale  the  size  of  web-based  multi-player  games  or 
simulations.  For  example,  the  lowest  receiving  rate  in  the  experiments  was 
around  1,900  PDUs  per  second,  which  was  achieved  when  sending  PDUs  by 
Chrome  browser  in  a  peer-to-peer  connection.  Based  on  this  result,  a  suggested 
number  of  players  can  be  found  by  using  equation  (1). 

Three  variables  that  had  to  be  considered:  number  of  entity  that  sent 
ESPDU  repeatedly,  heartbeat  rate,  and  number  of  clients;  multiplying  these  three 
variables  should  result  in  a  number  less  than  1,900.  This  tank  game  had  two 
entities:  tank  entity  and  tank’s  ammunition  entity;  both  entities  sent  ESPDU 
frequently.  Each  entity  had  its  own  heartbeat  rate.  Summing  up  the  heartbeat 
rates  multiplied  by  the  corresponding  entity  would  give  the  total  amount  of 
sending  ESPDUs  routinely,  which  excluded  sending  collision  PDU  and  fire  PDU. 
The  game  setting  of  the  heartbeat  frequencies  for  both  tank  and  tank’s 
ammunition  was  10ms,  which  was  equal  to  sending  100  ESPDUs  per  second. 
Therefore,  the  total  amount  of  sending  ESPDUs  was  around  200  per  second. 
The  last  variable  was  the  number  of  clients,  because  the  sending  technique  was 
one-by-one  on  peer-to-peer  connections  and  WebSocket  gateway  server.  The 
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multiplier  of  the  client  number  should  be  the  total  number  of  clients,  minus  the 
one  that  was  the  sending  client  itself.  Back  to  the  question,  the  suggested 
maximum  number  of  players  to  play  the  tank  game  was  10  (the  calculating  result 
was  1 0.5  with  the  equation  (1  *1 00+1  *1 00)*(TC-1 )  =  1 900). 


'ZE,*HRl  (rc-i)<2000 


M 


(1) 


where, 

n  =  total  number  of  entities. 

Ei  -  each  entity 

HRt  =  heartbeat  rate  for  the  corresponding  entity. 

TG  =  total  number  of  client 

Ten  players  were  not  the  maximum  number  playing  the  tank  game. 
Different  networking  frameworks  with  different  browsers  had  different  capabilities 
of  exchanging  DIS  packets.  In  addition,  there  are  other  ways  to  adjust  the  game 
capacity,  such  as  changing  the  number  of  entities  that  frequently  sent  ESPDUs, 
and  adjusting  the  heartbeat  rate.  One  example  was  modifying  the  JavaScript 
program  so  that  the  tank’s  ammunition  sent  ESPDUs  only  when  a  tank  fired, 
instead  of  the  projectile  sending  ESPDUs  periodically;  the  projectile  would  only 
send  ESPDUs  when  its  velocity  was  not  zero.  Another  way  was  to  adjust 
heartbeat  rate  on  each  entity.  The  rate  of  heartbeat  affected  game  animation  in 
participant’s  browsers  because  browsers  used  receiving  ESPDUs  to  update 
entity  positions  and  states.  At  100  ESPDUs  per  second,  the  effective  rendering 
rate  is  100  fps  in  the  remote  participants,  and  it  is  not  necessary  to  set  an 
identical  rate  on  both  heartbeat  and  canvas  rendering.  In  modern  video  games, 
30  fps  is  qualified  enough  to  be  a  commercial  game,  if  this  tank  game  lowered  its 
heartbeat  rates,  the  capacity  of  the  number  of  players  and/or  the  number  of 
entities  must  be  increased.  Appendix  F  shows  screenshots  of  multiplayers  in  the 
example  tank  game. 
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VII.  CONCLUSION  AND  FUTURE  WORKS 


A.  CONCLUSION 

The  objectives  of  this  thesis  were  to  discuss  and  prove  the  feasibility  of 
developing  DIS  web-based  simulations  using  JavaScript.  This  thesis 
incorporated  many  web  technologies  and  DIS  protocol  to  outline  infrastructures 
that  supported  web-based  simulation.  The  major  web  technologies  included 
JavaScript,  WebSocket,  WebRTC,  and  WebGL;  there  were  many  existing  APIs 
that  wrapped  WebRTC  and  WebGL  to  help  developers  create  web  applications. 
This  thesis  suggested  two  different  networking  architectures,  client-server  and 
peer-to-peer,  for  interchanging  DIS  messages;  and  tested  the  capability  of 
sending  and  receiving  DIS  PDUs  between  browsers.  Furthermore,  this  thesis 
also  integrated  the  above  technologies  to  develop  a  browser-based  tank  game 
as  a  test  application,  and  analyzed  the  performance  of  the  tank  game  in  different 
networking  frameworks.  At  the  same  time,  taking  the  advantage  of  cross-platform 
in  browsers,  both  performance  tests  and  the  tank  game  can  be  executed  and 
analyzed  in  Chrome  and  Firefox  browsers,  Internet  Explorer  and  Safari  did  not 
support  WebRTC  yet.  Other  benefits  of  using  web-based  simulation  included 
model  reusing,  collaboration,  deployment,  accessibility,  and  versioning  control. 

According  to  the  performance  tests  and  analysis  of  the  demonstrating  tank 
game,  this  thesis  found  that  the  modern  web  technologies  are  capable  enough  to 
construct  web-based  simulations.  The  performance  tests  included  the  capability 
of  simply  sending  and  receiving  DIS  PDUs  in  different  networking  frameworks; 
comparing  the  performance  between  the  applying  of  WebGL  materials;  and 
cross-browser  performances  between  Chrome  and  Firefox.  The  analysis  of  the 
tank  game  contained  the  resource  consumption  of  rendering  WebGL  materials 
and  interchanging  DIS  messages;  and  the  page  loads  of  necessary  files  from 
web  server.  The  followings  are  the  conclusions  for  the  performance  tests  and  the 
game  analyses. 
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The  performance  tests  showed  that  the  speed  of  executing  the  sending 
ESPDUs  function  was  faster  than  both  WebSocket  and  WebRTC  sent  DIS 
messages.  In  fact,  the  measurements  of  sending  rates  were  much  higher  than 
the  receiving  rates,  meaning  it  was  better  to  use  receiving  throughput  as  a 
reference  to  scale  the  size  of  web-based  simulation.  Both  Chrome  and  Firefox 
have  similar  performances  of  sending  and  receiving  DIS  PDUs  using  the 
WebSocket  framework.  The  performances  of  the  WebRTC  framework,  however, 
favored  Firefox.  While  using  Firefox  to  send  DIS  packets  via  the  WebRTC 
framework,  both  Chrome  and  Firefox  had  a  better  performance  than  any 
experiments  with  the  WebSocket  framework.  While  using  Chrome  to  send  the 
PDUs  via  the  WebRTC,  both  Chrome  and  Firefox  had  worse  performances  than 
all  the  experiments  with  the  WebSocket  framework.  Therefore,  the  Firefox  and 
WebRTC  combination  is  currently  better  than  other  combinations  provided 
WebRTC  is  implemented  using  PeerJS. 

This  thesis  used  the  worst-case  performance  of  receiving  rate  (around 
1,900  PDUs  per  second)  as  a  guidance  for  scaling  the  tank  game.  The  tank 
game  had  two  entities  that  repeatedly  sent  200  ESPDUs  per  second.  The 
calculating  result  showed  that  this  tank  game  was  suitable  for  up  to  ten  players. 
In  addition,  there  were  variables  that  could  be  adjusted  to  enlarge  the  capacity  of 
the  tank  game,  such  as  the  heartbeat  rate  or  the  amount  of  entity  that  periodically 
sent  ESPDU.  The  capacity  of  ten  players  was  good  enough  to  create  an  online 
game.  For  example,  ten  players  can  be  divided  into  five-versus-five  players. 
Famous  examples  of  five-versus-five  games  include  League  of  Legends  and 
Defense  of  the  Ancients  (DotA)  in  Warcraft  III;  however,  they  are  not  web-based 
games. 

This  thesis  used  Chrome  and  Firefox  developer  tools  to  profile  the  tank 
game  and  recode  the  time  of  loading  web  contents.  Profiling  tools  contained 
percentages  of  time  that  each  function  used,  and  explicit  times  of  each  function 
spent.  The  profiling  results  showed  most  of  the  browser  resources  were  spent  on 
WebGL  components,  and  the  function  for  exchanging  DIS  packets  only  used  a 
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small  portion  of  the  browser  resources  (see  Figure  33,  Figure  34,  Appendix  C-1, 
and  Appendix  C-2).  The  times  of  loading  web  contents  showed  browsers 
received  all  necessary  web  contents  quickly  in  a  closed  network  (see  Appendix 
D). 

Based  on  the  above  results,  the  DIS  protocol  could  be  applied  in  web- 
based  applications.  Both  WebSocket  and  WebRTC  frameworks  were  capable  of 
supporting  a  ten-player  first-person-shooter  game  in  a  browser,  and  the  size  of 
the  game  was  expandable  by  adjusting  the  variables.  WebGL  created  3D 
graphics  shows  in  web  browsers  without  any  plugins,  and  the  performance  of 
WebGL  was  dependent  on  the  power  of  computers  and  the  degree  of  model 
complexity,  which  was  a  trade-off  among  budget,  performance,  and  the  quality  of 
3D  models.  Methods  of  using  the  DIS  protocol  and  the  game  styles  are  varied. 
This  thesis  showed  that  web-based  DIS  simulation  is  workable,  and  simulation 
designers  could  refer  to  the  basic  capability  of  exchanging  DIS  messages  to 
develop  web-based  simulation  for  different  purposes. 

B.  FUTURE  WORKS 

This  thesis  sought  quick  ways  of  constructing  networking  environments  to 
interchange  DIS  between  different  browsers,  so  simulation  developers  could 
focus  on  the  functions  and  scenarios  for  different  purposes.  This  thesis  also 
focused  on  developing  an  example  game  as  a  practical  application  to  verify  the 
feasibility  of  web-based  simulation.  There  were  some  experiments  and 
improvements  that  were  not  performed  in  this  thesis,  such  as:  performance 
testing  of  mobile  devices;  improvement  of  the  WebRTC  sending  capability  in 
Chrome  browsers;  benchmark  testing  of  the  WebSocket  and  the  WebRTC  in 
different  browsers;  discussions  of  disadvantages  of  web-based  simulations;  and 
comparisons  between  web-based  DIS  simulations  and  traditional  DIS  simulations. 

1.  Performance  Tests  and  Web  Applications  on  Mobile  Devices 

The  development  of  mobile  devices  has  flourished  in  the  past  few  years, 

and  most  of  the  mobile  devices  have  installed  web  browsers  such  as  iOS  Safari, 
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Opera  Mini,  Android  Browser,  and  Chrome  for  Android.  One  of  the  advantages  of 
web  applications  is  cross-platform,  which  indicates  mobile  devices  can  execute 
web  applications  in  their  compatible  web  browsers.  Currently,  almost  every 
browser  supports  WebSocket,  except  Opera  Mini;  however,  only  Chrome  for 
Android  supports  the  WebRTC.  This  thesis  did  not  measure  the  performance  of 
interchanging  DIS  PDUs  between  browsers  in  mobile  devices.  This  result  would 
be  a  consideration  for  developing  web  applications,  because  the  computational 
performance  on  mobile  devices  is  typically  slower  than  personal  computers  or 
laptop  computers.  Other  considerations  include  WebGL  components  and  input 
mechanisms.  WebGL  is  one  of  the  major  elements  that  uses  a  lot  of  browser 
resources.  So  far  only  Chrome  for  Android  supports  WebGL,  but  the  next  version 
of  iOS  Safari  will  begin  supporting  WebGL(Deveria,  n.d.-a).  In  addition,  mobile 
devices  usually  do  not  attach  to  a  keyboard  or  mouse,  and  the  main  input  device 
for  mobile  device  is  a  touch  screen.  Therefore,  development  of  web  applications 
for  mobile  devices  has  to  take  into  consideration  input  mechanisms  using 
graphical  user  interfaces  (GUI)  for  users. 

2.  Improvement  of  WebRTC  Sending  Capability  in  Chrome 
Browser  and  Benchmark  Test 

According  to  the  results  in  Chapter  V,  Performance  Tests,  the  lowest 
receiving  rates  were  from  Chrome  sent  to  Chrome  and  Chrome  sent  to  Firefox. 
This  thesis  used  PeerJS  that  wrapped  WebRTC  to  create  data  channels  between 
browsers.  PeerJS  is  an  easy  and  convenient  API  for  developers  to  create  web 
applications  that  apply  WebRTC  functions  in  a  browser.  However,  because 
PeerJS  is  a  wrapped  API,  it  is  difficult  to  modify  or  change  the  JavaScript  code 
inside  the  API.  Additionally,  there  is  no  benchmark  application  for  testing 
WebRTC  performance  between  Chrome  and  Firefox.  Comparing  with  the 
receiving  capability  that  sending  from  Firefox  browser  (Figure  29),  it  seems  like 
Chrome  should  have  space  for  improvement  in  the  performance  of  the  WebRTC 
framework.  Therefore,  further  studies  directed  at  WebRTC  technology  are 
required  to  improve  the  sending  performance  of  the  Chrome  browser. 
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3.  Disadvantages  of  Web-based  Simulation 

This  thesis  discussed  the  advantages  of  web  applications,  along  with  the 
establishment  of  infrastructures  that  exchange  DIS  messages,  and  the 
development  of  the  tank  game.  Some  disadvantages  of  web-based  simulations 
were  not  studied  or  discussed  in  this  thesis,  such  as  security  vulnerability,  GUI 
limitation,  and  latency.  In  addition,  further  study  and  discussion  should  contain 
comparisons  between  web-based  DIS  simulation  and  traditional  DIS  simulation. 

4.  Feasibility  of  Other  Web-based  DIS  Applications 

This  thesis  only  developed  a  first-person-shooter  tank  game  as  an 
example  of  a  DIS  simulation  in  a  browser.  However,  applications  that  use  DIS 
protocols  are  varied.  Further  research  is  needed  to  discover  which  web-based 
domains  can  be  applied  to  DIS  simulations.  For  example,  the  WebSocket 
gateway  server  can  receive  native  DIS  from  a  UDP  socket,  so  browsers  can 
receive  DIS  packets  from  other  simulation  systems  such  as  VBS2.  Is  it  possible 
to  create  a  battlefield  viewer  by  receiving  DIS  messages  in  browsers,  or  to  create 
a  simplified  interactive  game  interface  in  browsers?  On  the  other  hand,  WebRTC 
emphasizes  real-time  communication  between  browsers,  and  is  designed  for 
audio  and  video  communication.  Is  it  possible  to  incorporate  audio  and  video  in 
web-based  DIS  simulations?  What  is  the  benefit  of  incorporating  audio  and  video 
in  web-based  simulations,  and  does  it  affect  the  performance  of  sending  and 
receiving  DIS  PDUs? 

5.  Performance  Tests  in  Public  Networking  Environments 

All  the  experiments  and  performance  tests  in  this  thesis  were  done  in  a 

closed-networking  environment.  Both  WebSocket  and  WebRTC  were  competent 

enough  to  support  web-based  DIS  simulations;  however,  a  public  networking 

environment  is  much  more  complex.  Both  WebSocket  gateway  servers  and 

WebRTC  peers  used  one-by-one  mechanisms  to  distribute  DIS  packets,  but  the 

bottom  layers  were  different.  The  WebSocket  was  based  on  a  TCP  socket,  and 

the  WebRTC  used  a  UDP  socket.  This  thesis  did  not  examine  performances  on  a 
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public  network  or  Internet  environments.  Additional  experiments  should  be  done 
to  compare  the  performance  between  the  WebSocket  and  the  WebRTC  on  a 
public  network. 
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APPENDIX  A.  TABLE  OF  ENTITY  STATE  PDU  FIELDS 


Appendix  A  shows  the  fields  of  entity  state  PDU,  and  DIS  simulation  uses 
ESPDU  to  communicate  information  about  an  entity’s  state. 
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where 

,V  is  tbejsnmber  of  Variable  Parame-c^f  mitfds. 

Table  6.  Fields  of  entity  state  PDU. 
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APPENDIX  B.  FIREFOX  DEVELOPER  TOOLS 
PERFORMANCE  PROFILE  RESULTS 


A.  APPENDIX  B-1 .  FIREFOX  PROFILING  OF  SENDING  ESPDUS 

Appendix  B-1  shows  a  result  of  using  Firefox  developer  tools  to  profile  the 
sending  behavior  in  the  WebSocket  framework  for  a  short  period-of-time. 
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Figure  41 .  Firefox  profiling  of  sending  ESPDU  in  the  WebSocket  framework. 
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APPENDIX  B-2.  SENDING  SECTION  IN  APPENDIX  B-1 

Appendix  B-2  shows  the  sending  section  in  Appendix  B1. 
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Figure  42.  Sending  section  in  Appendix  B1 . 
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APPENDIX  B-3.  FIREFOX  PROFILING  OF  RECEIVING  ESPDUS 


Appendix  B-3  shows  a  result  of  using  Firefox  developer  tools  to  profile  the 
receiving  behavior  in  the  WebSocket  framework  for  a  short  period-of-time. 


ea 

W\ 

€3 


£ 


1 

S 


K 

i 


—  +  *  +  +  +■+■  *  *  +  *  *  *  * 

. . . 

*,££££££  SEEEEEEEEEEE 


£  £  £ 


i  g  a  k  » 


Figure  43.  Firefox  profiling  of  receiving  ESPDU  in  the  WebSocket  framework. 


79 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


80 


APPENDIX  C.  TANK  GAME  RESULTS 


A.  APPENDIX  C-1.  FIREFOX  PROFILING  IN  THE  WEBSOCKET 
FRAMEWORK 

Appendix  C-1  shows  a  result  of  profiling  the  tank  game  using  Firefox 
developer  tools  in  the  WebSocket  framework. 
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Firefox  profiling  of  the  tank  game  in  the  WebSocket  framework. 
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APPENDIX  C-2.  FIREFOX  PROFILING  IN  THE  WEBRTC  FRAMEWORK 


Appendix  C-2  shows  a  result  of  profiling  the  tank  game  using  Firefox 
developer  tools  in  the  WebRTC  framework. 

3  Inifiertar  \ijj  Debugger  Style. Editor  .  ■  Hj  T-  Network 


Complete  Pfafile 


Ru--"iiirtg  Tit*  Self 


ij$d0  idfl  OS 

7M7 

^  l^onlj 

4579 

36.314 

6 

f  fi4/r«ode^Fuftci,?  Ct  dtailewtbpl  nrtiiti  551 

is  10 

* 

►  IfrfikTihis  ufHUloO  O  tenk  j*.&l 

1-054 

6.414 

0 

r  THREE  sVeijGLRendeyrier.Ihra.re-nde-! ;  ^  three  _p  33504 

s 

0  OS 

2 

»■  THREE  OdtectSO  prtfDtyj]*  addi ,  o  UirM.ja.7746 

2 

0  014 

2 

THftH  &r|rtCnn[rap.1ht5  mjhMIcs  s  ®  QrtsdCnntrgU  p:2?0 

1 

DOS 

1 

UunEtfVlM-  jgdak  ,  <g  *niuhfit0.fl 22 

Ki 

'0  714 

3 

1  OBlH4Ujnr«ccrflo  _&3>‘-,,^^r('D-4lBC6inr«L':his  _dc  onmei-ugei'i  e  pwrp..  lflftS 

90 

0.714 

9 

►  Ob  LaCan  nectar.  prctDlypc  _hflndleDaEHl7esini}'ei  .>  (3J  peer.p:  16 14 

23 

02% 

4 

*  rt-ifl-sflfittat"  fi  disnc^tdc  |,imi  HT 

11 

0  114 

9 

>  Cnl*£gn  nectar  prgEptyTK  *nrdi  >  @|  p«r  p  107E 

4 

0.014 

Z 

►  dft.EnU^teRa^r[ifl,EflttyStifldPau  grnltfljT>e  e “frtdeTdBma^CiEr  i  «  dr*  ji  3726 

4 

1 1.0% 

Q 

*  Iflr^T-sEvf  ryPfinj  ij  d^CWlOQl  hhrJ  690 

30 

0  2% 

17 

►  .r-i^lvp«  IHrtdtE-  -  _  MJT  ~ 

1® 

D  IS 

4 

►  4lim¥J^.|^pHf.Br1biflt4  r 

<7 

6.1% 

0 

►  TQi^lb  i  e  £;  !ie«  :>j-TtalilN.  s  1'  jpe 

5 

0.0% 

3 

►  i1IIAi^^eErtt£yl^t»r>^ih&H.dw£I^LHlPd852 

3 

0.0% 

Q 

►  _'***■■  I.?;  "  jr«' 

1 

O.&S 

C 

►  i  oofcprvei  jir 

1 

D.OS 

1 

1 

POTS 

1 

-  nwivn-'-  s-i  i  4|  Dea-p*tr^  rjw* furt*  FntaB,lr,.1-uiL*Tr-;  r  J*  qm *ttr 

1 

DOS 

0 

►  . . -«t  •  £  liivilr  .-J  -<  -C  • 

1 

0.OS 

0 

►  ,n,  -Hi  ■-  rjrn^  wr  ^ul  '  r^nv.wi 

Figure  45.  Firefox  profiling  of  the  tank  game  in  the  WebRTC  framework. 
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APPENDIX  D.  NETWORK  LOADING  TIME 


Appendix  D  is  an  example  of  recording  the  time  of  loading  web  contents. 


Figure  46.  Network  loading  time. 
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APPENDIX  E.  COMPARISONS  OF  RECEIVING  FIRST  TEN  10,000 
DIS  PDUS  IN  THE  LINEAR  FORM 


Appendix  E  is  the  comparisons  of  receiving  first  ten  10,000  DIS  PDUs  in 
the  linear  form.  It  shows  that  the  times  of  receiving  first  one  10,000  DIS  PDUs 
were  slower  when  the  senders  were  Chrome. 
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Figure  47.  The  comparisons  of  receiving  first  ten  10,000  DIS  PDUs 

in  the  linear  form. 
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APPENDIX  F.  SCREENSHOTS  OF  MULTIPLAYERS 
IN  THE  TANK  GAME 


Appendix  F  shows  that  it  is  possible  to  create  a  web-based  DIS  simulation 


for  many  users. 


Figure  48.  Screenshots  of  multiplayers  in  the  tank  game  I. 


Figure  49.  Screenshots  of  multiplayers  in  the  tank  game  II. 
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Figure  50.  Screenshots  of  multiplayers  in  the  tank  game  III. 


Figure  51 .  Screenshots  of  multiplayers  in  the  tank  game  IV. 
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